#
58107dd5 |
| 29-May-2012 |
Stepan Dyatkovskiy <stpworld@narod.ru> |
ConstantRangesSet renamed to IntegersSubset. CRSBuilder renamed to IntegersSubsetMapping.
llvm-svn: 157612
|
#
1ab17ed5 |
| 28-May-2012 |
David Blaikie <dblaikie@gmail.com> |
Remove unused variable.
llvm-svn: 157586
|
#
e17b69a3 |
| 28-May-2012 |
Meador Inge <meadori@gmail.com> |
PR12696: Attribute bits above 1<<30 are not encoded in bitcode
Attribute bits above 1<<30 are now encoded correctly. Additionally, the encoding/decoding functionality has been hoisted to helper fun
PR12696: Attribute bits above 1<<30 are not encoded in bitcode
Attribute bits above 1<<30 are now encoded correctly. Additionally, the encoding/decoding functionality has been hoisted to helper functions in Attributes.h in an effort to help the encoding/decoding to stay in sync with the Attribute bitcode definitions.
llvm-svn: 157581
show more ...
|
#
9704ed03 |
| 28-May-2012 |
Benjamin Kramer <benny.kra@googlemail.com> |
Random BitcodeReader cleanups.
llvm-svn: 157577
|
#
e3e19cbb |
| 28-May-2012 |
Stepan Dyatkovskiy <stpworld@narod.ru> |
PR1255: Case Ranges Implemented IntItem - the wrapper around APInt. Why not to use APInt item directly right now? 1. It will very difficult to implement case ranges as series of small patches. We got
PR1255: Case Ranges Implemented IntItem - the wrapper around APInt. Why not to use APInt item directly right now? 1. It will very difficult to implement case ranges as series of small patches. We got several large and heavy patches. Each patch will about 90-120 kb. If you replace ConstantInt with APInt in SwitchInst you will need to changes at the same time all Readers,Writers and absolutely all passes that uses SwitchInst. 2. We can implement APInt pool inside and save memory space. E.g. we use several switches that works with 256 bit items (switch on signatures, or strings). We can avoid value duplicates in this case. 3. IntItem can be easyly easily replaced with APInt. 4. Currenly we can interpret IntItem both as ConstantInt and as APInt. It allows to provide SwitchInst methods that works with ConstantInt for non-updated passes.
Why I need it right now? Currently I need to update SimplifyCFG pass (EqualityComparisons). I need to work with APInts directly a lot, so peaces of code ConstantInt *V = ...; if (V->getValue().ugt(AnotherV->getValue()) { ... } will look awful. Much more better this way: IntItem V = ConstantIntVal->getValue(); if (AnotherV < V) { }
Of course any reviews are welcome.
P.S.: I'm also going to rename ConstantRangesSet to IntegersSubset, and CRSBuilder to IntegersSubsetMapping (allows to map individual subsets of integers to the BasicBlocks). Since in future these classes will founded on APInt, it will possible to use them in more generic ways.
llvm-svn: 157576
show more ...
|
#
3cb6f83e |
| 28-May-2012 |
Chris Lattner <sabre@nondot.org> |
switch AttrListPtr::get to take an ArrayRef, simplifying a lot of clients.
llvm-svn: 157556
|
#
561dae09 |
| 23-May-2012 |
Nuno Lopes <nunoplopes@sapo.pt> |
revert r156383: removal of TYPE_CODE_FUNCTION_OLD Apparently LLVM only stopped emitting this after LLVM 3.0
llvm-svn: 157325
|
#
3dea4218 |
| 14-May-2012 |
Stepan Dyatkovskiy <stpworld@narod.ru> |
SwitchInst cosmetics: renamed "Hash" method to "hash"
llvm-svn: 156757
|
Revision tags: llvmorg-3.1.0 |
|
#
0beab5e1 |
| 12-May-2012 |
Stepan Dyatkovskiy <stpworld@narod.ru> |
Recommited r156374 with critical fixes in BitcodeReader/Writer: Ordinary patch for PR1255. Added new case-ranges orientated methods for adding/removing cases in SwitchInst. After this patch cases wil
Recommited r156374 with critical fixes in BitcodeReader/Writer: Ordinary patch for PR1255. Added new case-ranges orientated methods for adding/removing cases in SwitchInst. After this patch cases will internally representated as ConstantArray-s instead of ConstantInt, externally cases wrapped within the ConstantRangesSet object. Old methods of SwitchInst are also works well, but marked as deprecated. So on this stage we have no side effects except that I added support for case ranges in BitcodeReader/Writer, of course test for Bitcode is also added. Old "switch" format is also supported.
llvm-svn: 156704
show more ...
|
Revision tags: llvmorg-3.1.0-rc3 |
|
#
24ac479a |
| 08-May-2012 |
Nuno Lopes <nunoplopes@sapo.pt> |
remove autoupgrade code for old function attributes format. I still left another fixme regarding alignment, because I'm unsure how to remove that code without breaking things
llvm-svn: 156387
|
#
f7596c91 |
| 08-May-2012 |
Nuno Lopes <nunoplopes@sapo.pt> |
remove TYPE_CODE_FUNCTION_OLD type code. it is no longer in use and it was marked for removal in 3.0
llvm-svn: 156383
|
#
5eafce5c |
| 08-May-2012 |
Stepan Dyatkovskiy <stpworld@narod.ru> |
Rejected r156374: Ordinary PR1255 patch. Due to clang-x86_64-debian-fnt buildbot failure.
llvm-svn: 156377
|
#
b6a46401 |
| 08-May-2012 |
Stepan Dyatkovskiy <stpworld@narod.ru> |
Ordinary patch for PR1255. Added new case-ranges orientated methods for adding/removing cases in SwitchInst. After this patch cases will internally representated as ConstantArray-s instead of Constan
Ordinary patch for PR1255. Added new case-ranges orientated methods for adding/removing cases in SwitchInst. After this patch cases will internally representated as ConstantArray-s instead of ConstantInt, externally cases wrapped within the ConstantRangesSet object. Old methods of SwitchInst are also works well, but marked as deprecated. So on this stage we have no side effects except that I added support for case ranges in BitcodeReader/Writer, of course test for Bitcode is also added. Old "switch" format is also supported.
llvm-svn: 156374
show more ...
|
Revision tags: llvmorg-3.1.0-rc2, llvmorg-3.1.0-rc1 |
|
#
92ef975c |
| 29-Feb-2012 |
Derek Schuff <dschuff@google.com> |
Fix PR12080 by ensuring that MaterializeModule actually reads all the bitcode in the streaming case.
llvm-svn: 151676
|
#
8b2dcad4 |
| 06-Feb-2012 |
Derek Schuff <dschuff@google.com> |
Enable streaming of bitcode
This CL delays reading of function bodies from initial parse until materialization, allowing overlap of compilation with bitcode download.
llvm-svn: 149918
|
#
b7d8f21a |
| 06-Feb-2012 |
Bill Wendling <isanbard@gmail.com> |
[unwind removal] Remove the 'unwind' instruction parsing bits.
llvm-svn: 149897
|
#
206dddda |
| 06-Feb-2012 |
Derek Schuff <dschuff@google.com> |
Test commit; also removes some trailing whitespace
llvm-svn: 149887
|
#
bb8278a1 |
| 05-Feb-2012 |
Chris Lattner <sabre@nondot.org> |
Improve the bitcode reader's handling of constant strings to use ConstantDataArray::getString direction, instead of "boxing" each byte into a ConstantInt and using ConstantArray::get.
llvm-svn: 1498
Improve the bitcode reader's handling of constant strings to use ConstantDataArray::getString direction, instead of "boxing" each byte into a ConstantInt and using ConstantArray::get.
llvm-svn: 149805
show more ...
|
#
372dd1ea |
| 30-Jan-2012 |
Chris Lattner <sabre@nondot.org> |
Add bitcode reader and writer support for ConstantDataAggregate, which should be feature complete now. Lets see if it works.
llvm-svn: 149215
|
#
cc3aaf18 |
| 27-Jan-2012 |
Chris Lattner <sabre@nondot.org> |
smallvectorize.
llvm-svn: 149117
|
#
a5054ad2 |
| 20-Jan-2012 |
Kostya Serebryany <kcc@google.com> |
Extend Attributes to 64 bits
Problem: LLVM needs more function attributes than currently available (32 bits). One such proposed attribute is "address_safety", which shows that a function is being ch
Extend Attributes to 64 bits
Problem: LLVM needs more function attributes than currently available (32 bits). One such proposed attribute is "address_safety", which shows that a function is being checked for address safety (by AddressSanitizer, SAFECode, etc).
Solution: - extend the Attributes from 32 bits to 64-bits - wrap the object into a class so that unsigned is never erroneously used instead - change "unsigned" to "Attributes" throughout the code, including one place in clang. - the class has no "operator uint64 ()", but it has "uint64_t Raw() " to support packing/unpacking. - the class has "safe operator bool()" to support the common idiom: if (Attributes attr = getAttrs()) useAttrs(attr); - The CTOR from uint64_t is marked explicit, so I had to add a few explicit CTOR calls - Add the new attribute "address_safety". Doing it in the same commit to check that attributes beyond first 32 bits actually work. - Some of the functions from the Attribute namespace are worth moving inside the class, but I'd prefer to have it as a separate commit.
Tested: "make check" on Linux (32-bit and 64-bit) and Mac (10.6) built/run spec CPU 2006 on Linux with clang -O2.
This change will break clang build in lib/CodeGen/CGCall.cpp. The following patch will fix it.
llvm-svn: 148553
show more ...
|
#
b7993465 |
| 02-Jan-2012 |
Rafael Espindola <rafael.espindola@gmail.com> |
Materialize functions whose basic blocks are used by global variables. Fixes PR11677.
llvm-svn: 147425
|
#
518cda42 |
| 17-Dec-2011 |
Dan Gohman <gohman@apple.com> |
The powers that be have decided that LLVM IR should now support 16-bit "half precision" floating-point with a first-class type.
This patch adds basic IR support (but not codegen support).
llvm-svn:
The powers that be have decided that LLVM IR should now support 16-bit "half precision" floating-point with a first-class type.
This patch adds basic IR support (but not codegen support).
llvm-svn: 146786
show more ...
|
#
ca2567b8 |
| 07-Dec-2011 |
Chad Rosier <mcrosier@apple.com> |
Begin adding experimental support for preserving use-list ordering of bitcode files. First, add a new block USELIST_BLOCK to the bitcode format. This is where USELIST_CODE_ENTRYs will be stored.
Begin adding experimental support for preserving use-list ordering of bitcode files. First, add a new block USELIST_BLOCK to the bitcode format. This is where USELIST_CODE_ENTRYs will be stored. The format of the USELIST_CODE_ENTRYs have not yet been defined. Add support in the BitcodeReader for parsing the USELIST_BLOCK. Part of rdar://9860654 and PR5680.
llvm-svn: 146078
show more ...
|
#
90ef78c0 |
| 27-Nov-2011 |
Chris Lattner <sabre@nondot.org> |
remove autoupgrade support for really old-style debug info intrinsics. I think this is the last of autoupgrade that can be removed in 3.1. Can the atomic upgrade stuff also go?
llvm-svn: 145169
|