aboutsummaryrefslogtreecommitdiff
path: root/lib/VMCore/Constants.cpp
AgeCommit message (Collapse)Author
2013-01-02Rename VMCore directory to IR.Chandler Carruth
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) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171359 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-03Use the new script to sort the includes of every file under lib.Chandler Carruth
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. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-17Add a new function to ConstantExpr - getAsInstruction. This returns its ↵James Molloy
Instruction* corollary, which may be useful if a user wishes to transform a ConstantExpr so that one of its operands is no longer constant. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168262 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-16Constant::IsThreadDependent(): Use dyn_cast<Constant> instead of castHans Wennborg
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168147 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-15Make GlobalOpt be conservative with TLS variables (PR14309)Hans Wennborg
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168037 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-13Relax the restrictions on vector of pointer types, and vector getelementptr.Duncan Sands
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167828 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-24Back out r166591, not sure why this made it through since I cancelled the ↵Micah Villmow
command. Bleh, sorry about this! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166596 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-24Delete a directory that wasn't supposed to be checked in yet.Micah Villmow
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166591 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-13Fixed few warnings; trimmed empty lines.Galina Kistanova
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160159 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-13When linearizing a multiplication, return at once if we see a factor of zero,Duncan Sands
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158398 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-12Now that Reassociate's LinearizeExprTree can look through arbitrary expressionDuncan Sands
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158358 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-07Reserve space in these vectors to prevent having to grow the array tooBill Wendling
much. This gets us an addition 0.9% on 445.gobmk. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149952 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-05Convert assert(0) to llvm_unreachableCraig Topper
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149849 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-05Efficient Constant Uniquing.Talin
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149848 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-05reapply the patches reverted in r149470 that reenable ConstantDataArray,Chris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149800 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-01Revert Chris' commits up to r149348 that started causing VMCoreTests unit ↵Argyrios Kyrtzidis
test to fail. These are: r149348 r149351 r149352 r149354 r149356 r149357 r149361 r149362 r149364 r149365 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149470 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-31eliminate the "string" form of ConstantArray::get, usingChris Lattner
ConstantDataArray::getString instead. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149365 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-31with recent changes, ConstantArray is never a "string". Remove the associatedChris Lattner
methods and constant fold the clients to false. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149362 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-31fix a small oversight that broke the fhourstones app.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149357 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-31Change ConstantArray::get to form a ConstantDataArray when possible,Chris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149351 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-30Various improvements suggested by DuncanChris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149255 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-30First step of flipping on ConstantDataSequential: enable ConstantDataVectorChris Lattner
to be formed whenever ConstantVector::get is used. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149226 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-27continue making the world safe for ConstantDataVector. At this point,Chris Lattner
we should (theoretically optimize and codegen ConstantDataVector as well as ConstantVector. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149116 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-26smallvectorize and ArrayRef'ize some stuff.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149077 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-26Reduce a lot of code duplication by implementing Chris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149076 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-26eliminate the Constant::getVectorElements method. There are better (andChris Lattner
more robust) ways to do what it was doing now. Also, add static methods for decoding a ShuffleVector mask. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149028 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-26Add a ConstantDataVector::getSplatValue() method, for parity withChris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149021 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-26some general cleanup, using new methods and tidying up old code.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149006 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-25constify some methods and add a new Constant::getAggregateElementChris Lattner
helper method for the common operation of extracting an element out of a constant aggregate. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148931 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-25reapply r148901 with a crucial fix.Chris Lattner
"Introduce a new ConstantVector::getSplat constructor function to simplify a really common case." git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148924 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-25Fix assert("msg"). Fix unused-variable warnings complaining about VT used onlyNick Lewycky
in asserts. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148910 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-25Revert r148901 because it crashes llvm tests.Argyrios Kyrtzidis
Original log: Introduce a new ConstantVector::getSplat constructor function to simplify a really common case. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148906 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-25Introduce a new ConstantVector::getSplat constructor function to Chris Lattner
simplify a really common case. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148901 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-25Remove the Type::getNumElements() method, which is only called in 4 places,Chris Lattner
did something extremely surprising, and shadowed actually useful implementations that had completely different behavior. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148898 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-24C++, CBE, and TLOF support for ConstantDataSequentialChris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148805 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-24Rearrange argument order of ::get methods so that LLVMContext comes first,Chris Lattner
add a ConstantDataArray::getString method that corresponds to the (to be removed) StringRef version of ConstantArray::get, but is dramatically more efficient. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148804 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-24add more support for ConstantDataSequentialChris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148802 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-24Add AsmPrinter (aka MCLowering) support for ConstantDataSequential, Chris Lattner
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148793 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-24Add various "string" methods to ConstantDataSequential, which have theChris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148792 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-24teach valuetracking about ConstantDataSequentialChris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148790 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-24Add some accessor methods to CAZ and UndefValue that help simplify clients.Chris Lattner
Make some CDS methods public. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148785 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-24implement the ConstantDataSequential accessor methods.Chris Lattner
No need for 'getOperand' :) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148778 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-23start the implementation of a new ConstantDataVector and ConstantDataArrayChris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148741 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-23convert CAZ, UndefValue, and CPN to use DenseMap's again, this time withoutChris Lattner
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 :) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148700 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-23revert r148691 and 148693Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148698 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-23switch UndefValue and ConstantPointerNull over to DenseMap's for uniquing.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148693 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-23Replace a use of ConstantUniqueMap for CAZ constants with a simple DenseMap.Chris Lattner
Now that the type system rewrite has landed, there is no need for its complexity and std::map'ness. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148691 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-20More dead code removal (using -Wunreachable-code)David Blaikie
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148578 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-20Unweaken vtables as per ↵David Blaikie
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146960 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-17The powers that be have decided that LLVM IR should now support 16-bitDan Gohman
"half precision" floating-point with a first-class type. This patch adds basic IR support (but not codegen support). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146786 91177308-0d34-0410-b5e6-96231b3b80d8