summaryrefslogtreecommitdiffstats
path: root/llvm/lib/VMCore/Constants.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Add support for vectors of pointers.Nadav Rotem2011-12-051-4/+12
| | | | llvm-svn: 145801
* Fold ConstantVector::isAllOnesValue into Constant::isAllOnesValue and ↵Benjamin Kramer2011-11-141-22/+4
| | | | | | simplify it. llvm-svn: 144555
* Change:Richard Trieu2011-09-211-1/+1
| | | | | | | | | | | | assert(!"error message"); To: assert(0 && "error message"); which is more consistant across the code base. llvm-svn: 140234
* Implement Constant::isAllOnesValue(). Fix ConstantFolding to use the new api.Nadav Rotem2011-08-241-3/+21
| | | | llvm-svn: 138469
* Revert "Address Duncan's CR request:"Eric Christopher2011-08-231-21/+3
| | | | | | | | | | This reverts commit 20a05be15ea5271ab6185b83200fa88263362400. (svn rev 138340) Conflicts: test/Transforms/InstCombine/bitcast.ll llvm-svn: 138366
* Address Duncan's CR request:Nadav Rotem2011-08-231-3/+21
| | | | | | | 1. Cleanup the tests in ConstantFolding.cpp 2. Implement isAllOnes for Constant, ConstantFP, ConstantVector llvm-svn: 138340
* strengthen up an assertion: you can't create a constant structChris Lattner2011-08-071-2/+2
| | | | | | | with an opaque struct type, it doesn't make sense. This should resolve PR10473. llvm-svn: 137028
* Use ArrayRef in the (protected) constructors of ConstantArray, ↵Jay Foad2011-07-251-27/+12
| | | | | | ConstantStruct and ConstantVector. llvm-svn: 135905
* Convert GetElementPtrInst to use ArrayRef.Jay Foad2011-07-251-2/+1
| | | | llvm-svn: 135904
OpenPOWER on IntegriCloud