summaryrefslogtreecommitdiffstats
path: root/llvm/lib/VMCore/Constants.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Rename VMCore directory to IR.Chandler Carruth2013-01-021-2769/+0
| | | | | | | | | | | | | | | | | | Aside from moving the actual files, this patch only updates the build system and the source file comments under lib/... that are relevant. I'll be updating other docs and other files in smaller subsequnet commits. While I've tried to test this, but it is entirely possible that there will still be some build system fallout. Also, note that I've not changed the library name itself: libLLVMCore.a is still the library name. I'd be interested in others' opinions about whether we should rename this as well (I think we should, just not sure what it might break) llvm-svn: 171359
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-8/+8
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Add a new function to ConstantExpr - getAsInstruction. This returns its ↵James Molloy2012-11-171-0/+63
| | | | | | | | Instruction* corollary, which may be useful if a user wishes to transform a ConstantExpr so that one of its operands is no longer constant. llvm-svn: 168262
* Constant::IsThreadDependent(): Use dyn_cast<Constant> instead of castHans Wennborg2012-11-161-1/+3
| | | | | | | | | | | It turns out that the operands of a Constant are not always themselves Constant. For example, one of the operands of BlockAddress is BasicBlock, which is not a Constant. This should fix the dragonegg-x86_64-linux-gcc-4.6-test build which broke in r168037. llvm-svn: 168147
* Make GlobalOpt be conservative with TLS variables (PR14309)Hans Wennborg2012-11-151-0/+25
| | | | | | | | | | | | | | For global variables that get the same value stored into them everywhere, GlobalOpt will replace them with a constant. The problem is that a thread-local GlobalVariable looks like one value (the address of the TLS var), but is different between threads. This patch introduces Constant::isThreadDependent() which returns true for thread-local variables and constants which depend on them (e.g. a GEP into a thread-local array), and teaches GlobalOpt not to track such values. llvm-svn: 168037
* Relax the restrictions on vector of pointer types, and vector getelementptr.Duncan Sands2012-11-131-3/+38
| | | | | | | | | | | | | | | Previously in a vector of pointers, the pointer couldn't be any pointer type, it had to be a pointer to an integer or floating point type. This is a hassle for dragonegg because the GCC vectorizer happily produces vectors of pointers where the pointer is a pointer to a struct or whatever. Vector getelementptr was restricted to just one index, but now that vectors of pointers can have any pointer type it is more natural to allow arbitrary vector getelementptrs. There is however the issue of struct GEPs, where if each lane chose different struct fields then from that point on each lane will be working down into unrelated types. This seems like too much pain for too little gain, so when you have a vector struct index all the elements are required to be the same. llvm-svn: 167828
* Back out r166591, not sure why this made it through since I cancelled the ↵Micah Villmow2012-10-241-1/+1
| | | | | | command. Bleh, sorry about this! llvm-svn: 166596
* Delete a directory that wasn't supposed to be checked in yet.Micah Villmow2012-10-241-1/+1
| | | | llvm-svn: 166591
* Fixed few warnings; trimmed empty lines.Galina Kistanova2012-07-131-123/+151
| | | | llvm-svn: 160159
* When linearizing a multiplication, return at once if we see a factor of zero,Duncan Sands2012-06-131-2/+23
| | | | | | | | | since then the entire expression must equal zero (similarly for other operations with an absorbing element). With this in place a bunch of reassociate code for handling constants is dead since it is all taken care of when linearizing. No intended functionality change. llvm-svn: 158398
* Now that Reassociate's LinearizeExprTree can look through arbitrary expressionDuncan Sands2012-06-121-0/+20
| | | | | | | | | | | | | | | | | topologies, it is quite possible for a leaf node to have huge multiplicity, for example: x0 = x*x, x1 = x0*x0, x2 = x1*x1, ... rapidly gives a value which is x raised to a vast power (the multiplicity, or weight, of x). This patch fixes the computation of weights by correctly computing them no matter how big they are, rather than just overflowing and getting a wrong value. It turns out that the weight for a value never needs more bits to represent than the value itself, so it is enough to represent weights as APInts of the same bitwidth and do the right overflow-avoiding dance steps when computing weights. As a side-effect it reduces the number of multiplies needed in some cases of large powers. While there, in view of external uses (eg by the vectorizer) I made LinearizeExprTree static, pushing the rank computation out into users. This is progress towards fixing PR13021. llvm-svn: 158358
* Reserve space in these vectors to prevent having to grow the array tooBill Wendling2012-02-071-3/+4
| | | | | | much. This gets us an addition 0.9% on 445.gobmk. llvm-svn: 149952
* Convert assert(0) to llvm_unreachableCraig Topper2012-02-051-4/+3
| | | | llvm-svn: 149849
* Efficient Constant Uniquing.Talin2012-02-051-21/+19
| | | | llvm-svn: 149848
* reapply the patches reverted in r149470 that reenable ConstantDataArray,Chris Lattner2012-02-051-105/+91
| | | | | | | | | but with a critical fix to the SelectionDAG code that optimizes copies from strings into immediate stores: the previous code was stopping reading string data at the first nul. Address this by adding a new argument to llvm::getConstantStringInfo, preserving the behavior before the patch. llvm-svn: 149800
* Revert Chris' commits up to r149348 that started causing VMCoreTests unit ↵Argyrios Kyrtzidis2012-02-011-91/+105
| | | | | | | | | | | | | | | | | | | test to fail. These are: r149348 r149351 r149352 r149354 r149356 r149357 r149361 r149362 r149364 r149365 llvm-svn: 149470
* eliminate the "string" form of ConstantArray::get, usingChris Lattner2012-01-311-6/+0
| | | | | | ConstantDataArray::getString instead. llvm-svn: 149365
* with recent changes, ConstantArray is never a "string". Remove the associatedChris Lattner2012-01-311-63/+0
| | | | | | methods and constant fold the clients to false. llvm-svn: 149362
* fix a small oversight that broke the fhourstones app.Chris Lattner2012-01-311-1/+1
| | | | llvm-svn: 149357
* Change ConstantArray::get to form a ConstantDataArray when possible,Chris Lattner2012-01-311-38/+93
| | | | | | | | | | | | | | | kicking in the big win of ConstantDataArray. As part of this, change the implementation of GetConstantStringInfo in ValueTracking to work with ConstantDataArray (and not ConstantArray) making it dramatically, amazingly, more efficient in the process and renaming it to getConstantStringInfo. This keeps around a GetConstantStringInfo entrypoint that (grossly) forwards to getConstantStringInfo and constructs the std::string required, but existing clients should move over to getConstantStringInfo instead. llvm-svn: 149351
* Various improvements suggested by DuncanChris Lattner2012-01-301-1/+1
| | | | llvm-svn: 149255
* First step of flipping on ConstantDataSequential: enable ConstantDataVectorChris Lattner2012-01-301-7/+89
| | | | | | to be formed whenever ConstantVector::get is used. llvm-svn: 149226
* continue making the world safe for ConstantDataVector. At this point,Chris Lattner2012-01-271-6/+6
| | | | | | | we should (theoretically optimize and codegen ConstantDataVector as well as ConstantVector. llvm-svn: 149116
* smallvectorize and ArrayRef'ize some stuff.Chris Lattner2012-01-261-3/+3
| | | | llvm-svn: 149077
* Reduce a lot of code duplication by implementing Chris Lattner2012-01-261-138/+16
| | | | | | | | | ConstantExpr::getWithOperandReplaced and ConstantExpr::replaceUsesOfWithOnConstant in terms of ConstantExpr::getWithOperands. While we're at it, make sure that ConstantExpr::getWithOperands covers all instructions: it was missing insert/extractvalue. llvm-svn: 149076
* eliminate the Constant::getVectorElements method. There are better (andChris Lattner2012-01-261-30/+0
| | | | | | | more robust) ways to do what it was doing now. Also, add static methods for decoding a ShuffleVector mask. llvm-svn: 149028
* Add a ConstantDataVector::getSplatValue() method, for parity withChris Lattner2012-01-261-39/+87
| | | | | | | | | | ConstantVector. Fix some outright bugs in the implementation of ConstantArray and Constant struct, which would cause us to not make one big UndefValue when asking for an array/struct with all undef elements. Enhance Constant::isAllOnesValue to work with ConstantDataVector. llvm-svn: 149021
* some general cleanup, using new methods and tidying up old code.Chris Lattner2012-01-261-26/+21
| | | | llvm-svn: 149006
* constify some methods and add a new Constant::getAggregateElementChris Lattner2012-01-251-8/+41
| | | | | | | helper method for the common operation of extracting an element out of a constant aggregate. llvm-svn: 148931
* reapply r148901 with a crucial fix.Chris Lattner2012-01-251-31/+59
| | | | | | | "Introduce a new ConstantVector::getSplat constructor function to simplify a really common case." llvm-svn: 148924
* Fix assert("msg"). Fix unused-variable warnings complaining about VT used onlyNick Lewycky2012-01-251-5/+8
| | | | | | in asserts. llvm-svn: 148910
* Revert r148901 because it crashes llvm tests.Argyrios Kyrtzidis2012-01-251-55/+28
| | | | | | | | Original log: Introduce a new ConstantVector::getSplat constructor function to simplify a really common case. llvm-svn: 148906
* Introduce a new ConstantVector::getSplat constructor function to Chris Lattner2012-01-251-28/+55
| | | | | | simplify a really common case. llvm-svn: 148901
* Remove the Type::getNumElements() method, which is only called in 4 places,Chris Lattner2012-01-251-5/+11
| | | | | | | did something extremely surprising, and shadowed actually useful implementations that had completely different behavior. llvm-svn: 148898
* C++, CBE, and TLOF support for ConstantDataSequentialChris Lattner2012-01-241-1/+2
| | | | llvm-svn: 148805
* Rearrange argument order of ::get methods so that LLVMContext comes first,Chris Lattner2012-01-241-14/+28
| | | | | | | | add a ConstantDataArray::getString method that corresponds to the (to be removed) StringRef version of ConstantArray::get, but is dramatically more efficient. llvm-svn: 148804
* add more support for ConstantDataSequentialChris Lattner2012-01-241-3/+8
| | | | llvm-svn: 148802
* Add AsmPrinter (aka MCLowering) support for ConstantDataSequential, Chris Lattner2012-01-241-12/+6
| | | | | | | | and clean up some other misc stuff. Unlike ConstantArray, we will prefer to emit .fill directives for "String" arrays that all have the same value, since they are denser than emitting a .ascii llvm-svn: 148793
* Add various "string" methods to ConstantDataSequential, which have theChris Lattner2012-01-241-0/+27
| | | | | | | | same semantics as ConstantArray's but much more efficient because they don't have to return std::string's. The ConstantArray methods will eventually be removed. llvm-svn: 148792
* teach valuetracking about ConstantDataSequentialChris Lattner2012-01-241-0/+18
| | | | llvm-svn: 148790
* Add some accessor methods to CAZ and UndefValue that help simplify clients.Chris Lattner2012-01-241-6/+60
| | | | | | Make some CDS methods public. llvm-svn: 148785
* implement the ConstantDataSequential accessor methods.Chris Lattner2012-01-241-3/+93
| | | | | | No need for 'getOperand' :) llvm-svn: 148778
* start the implementation of a new ConstantDataVector and ConstantDataArrayChris Lattner2012-01-231-0/+148
| | | | | | | classes, per PR1324. Not all of their helper functions are implemented, nothing creates them, and the rest of the compiler doesn't handle them yet. llvm-svn: 148741
* convert CAZ, UndefValue, and CPN to use DenseMap's again, this time withoutChris Lattner2012-01-231-8/+21
| | | | | | | | using OwningPtr. OwningPtr would barf when the densemap had to reallocate, which doesn't appear to happen on the regression test suite, but obviously happens in real life :) llvm-svn: 148700
* revert r148691 and 148693Chris Lattner2012-01-231-54/+8
| | | | llvm-svn: 148698
* switch UndefValue and ConstantPointerNull over to DenseMap's for uniquing.Chris Lattner2012-01-231-4/+35
| | | | llvm-svn: 148693
* Replace a use of ConstantUniqueMap for CAZ constants with a simple DenseMap.Chris Lattner2012-01-231-4/+19
| | | | | | | Now that the type system rewrite has landed, there is no need for its complexity and std::map'ness. llvm-svn: 148691
* More dead code removal (using -Wunreachable-code)David Blaikie2012-01-201-3/+0
| | | | llvm-svn: 148578
* Unweaken vtables as per ↵David Blaikie2011-12-201-0/+6
| | | | | | http://llvm.org/docs/CodingStandards.html#ll_virtual_anch llvm-svn: 146960
* The powers that be have decided that LLVM IR should now support 16-bitDan Gohman2011-12-171-5/+22
| | | | | | | | "half precision" floating-point with a first-class type. This patch adds basic IR support (but not codegen support). llvm-svn: 146786
OpenPOWER on IntegriCloud