summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Constants.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [Constants] don't die processing non-ConstantInt GEP indices in ↵Sanjay Patel2016-12-111-6/+8
| | | | | | | | | isGEPWithNoNotionalOverIndexing() (PR31262) This should fix: https://llvm.org/bugs/show_bug.cgi?id=31262 llvm-svn: 289401
* IR: Move NumElements field from {Array,Vector}Type to SequentialType.Peter Collingbourne2016-12-021-4/+2
| | | | | | | | | | Now that PointerType is no longer a SequentialType, all SequentialTypes have an associated number of elements, so we can move that information to the base class, allowing for a number of simplifications. Differential Revision: https://reviews.llvm.org/D27122 llvm-svn: 288464
* IR: Change the gep_type_iterator API to avoid always exposing the "current" ↵Peter Collingbourne2016-12-021-9/+4
| | | | | | | | | | | | | type. Instead, expose whether the current type is an array or a struct, if an array what the upper bound is, and if a struct the struct type itself. This is in preparation for a later change which will make PointerType derive from Type rather than SequentialType. Differential Revision: https://reviews.llvm.org/D26594 llvm-svn: 288458
* IR: Introduce inrange attribute on getelementptr indices.Peter Collingbourne2016-11-101-4/+9
| | | | | | | | | | | | | | | | | If the inrange keyword is present before any index, loading from or storing to any pointer derived from the getelementptr has undefined behavior if the load or store would access memory outside of the bounds of the element selected by the index marked as inrange. This can be used, e.g. for alias analysis or to split globals at element boundaries where beneficial. As previously proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html Differential Revision: https://reviews.llvm.org/D22793 llvm-svn: 286514
* Use unique_ptr in LLVMContextImpl's constant maps.Justin Lebar2016-10-101-16/+18
| | | | | | | | | | Reviewers: timshen Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25419 llvm-svn: 283767
* [Constant] remove fdiv and frem from canTrap()Sanjay Patel2016-08-291-2/+0
| | | | | | | | | | | Assuming the default FP env, we should not treat fdiv and frem any differently in terms of trapping behavior than any other FP op. Ie, FP ops do not trap with the default FP env. This matches how we treat the fdiv/frem in IR with isSafeToSpeculativelyExecute() and in the backend after: https://reviews.llvm.org/rL279970 llvm-svn: 279973
* Apply clang-tidy's modernize-loop-convert to most of lib/IR.Benjamin Kramer2016-06-261-2/+2
| | | | | | Only minor manual fixes. No functionality change intended. llvm-svn: 273813
* [IR] Require ArrayRef of 'uint32_t' instead of 'int' for the mask argument ↵Craig Topper2016-06-121-5/+0
| | | | | | for one of the signatures of CreateShuffleVector. This better emphasises that you can't use it for the -1 as undef behavior. llvm-svn: 272491
* [IR] Teach the ArrayRef<int> form of IRBuilder::CreateShuffleVector to use ↵Craig Topper2016-05-291-0/+5
| | | | | | | | ConstantDataVector. This will be used in a follow up commit to simplify code in clang that creates a ConstantDataVector and calls the other form. llvm-svn: 271164
* fix formatting; NFCSanjay Patel2016-05-181-6/+3
| | | | llvm-svn: 269990
* Vector GEP - fixed a crash on InstSimplify Pass.Elena Demikhovsky2016-05-151-7/+16
| | | | | | | | Vector GEP with mixed (vector and scalar) indices failed on the InstSimplify Pass when all indices are constants. Differential revision http://reviews.llvm.org/D20149 llvm-svn: 269590
* clean up documentation comments; NFCSanjay Patel2016-04-291-110/+14
| | | | llvm-svn: 268122
* [NFC] Header cleanupMehdi Amini2016-04-181-3/+0
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* IR: Introduce ConstantAggregate, NFCDuncan P. N. Exon Smith2016-04-051-34/+24
| | | | | | | | | | | | Add a common parent class for ConstantArray, ConstantVector, and ConstantStruct called ConstantAggregate. These are the aggregate subclasses of Constant that take operands. This is mainly a cleanup, adding common `isa` target and removing duplicated code. However, it also simplifies caching which constants point transitively at `GlobalValue` (a possible future direction). llvm-svn: 265466
* IR: Add missing assertion for ConstantVector::ConstantVectorDuncan P. N. Exon Smith2016-04-051-0/+2
| | | | | | | Use the same assertion as ConstantArray. Vectors should have the right number of elements. llvm-svn: 265463
* IR: Add ConstantData, for operand-less ConstantsDuncan P. N. Exon Smith2016-02-211-32/+6
| | | | | | | | | | | | | Add a common parent `ConstantData` to the constants that have no operands. These are guaranteed to represent abstract data that is in no way tied to a specific Module. This is a good cleanup on its own. It also makes it simpler to disallow RAUW (and factor away use-lists) on these constants in the future. (I have some experimental patches that make RAUW illegal on ConstantData, and they seem to catch a bunch of bugs...) llvm-svn: 261464
* Simplify handleOperandChangeImpl() removing last argument (NFC)Mehdi Amini2016-02-101-49/+41
| | | | | | | | | | The Use argument was used to compute the operand number for a fast path when replacing only one operand. However we always have to go through all the operands. So the argument number can be recomputed locally anyway. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 260454
* [opaque pointer types] [NFC] GEP: replace get(Pointer)ElementType uses with ↵Eduard Burtescu2016-01-191-1/+6
| | | | | | | | | | | | | | | | | | get{Source,Result}ElementType. Summary: GEPOperator: provide getResultElementType alongside getSourceElementType. This is made possible by adding a result element type field to GetElementPtrConstantExpr, which GetElementPtrInst already has. GEP: replace get(Pointer)ElementType uses with get{Source,Result}ElementType. Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16275 llvm-svn: 258145
* [IR] Add classof for GetElementPtrConstantExpr, CompareConstantExpr, ↵Craig Topper2015-12-151-2/+1
| | | | | | | | InsertValueConstantExpr, and ExtractValueConstantExpr. All but CompareConstantExpr were being used in casts that were erroneously using ConstantExpr::classof due to inheritance. While there use cast<CompareConstantExpr> to simplify code slightly. I believe in one place we were always casting to ExtractValueConstantExpr when we were trying to choose between ExtractValueConstantExpr and InsertValueConstantExpr because of this. But since they have identical layouts this didn't cause any observable problems. llvm-svn: 255624
* Use CmpInst::Predicate instead of 'unsigned short' in some places. NFCCraig Topper2015-12-151-1/+1
| | | | llvm-svn: 255623
* IR: Make ConstantDataArray::getFP actually return a ConstantDataArrayJustin Bogner2015-12-091-1/+1
| | | | | | | | | | The ConstantDataArray::getFP(LLVMContext &, ArrayRef<uint16_t>) overload has had a typo in it since it was written, where it will create a Vector instead of an Array. This obviously doesn't work at all, but it turns out that until r254991 there weren't actually any callers of this overload. Fix the typo and add some test coverage. llvm-svn: 255157
* IR: Allow vectors of halfs to be ConstantDataVectorsJustin Bogner2015-12-081-3/+15
| | | | | | | | Currently, vectors of halfs end up as ConstantVectors, but there isn't a good reason they can't be ConstantDataVectors. This should save some memory. llvm-svn: 254991
* IR: Clean up some duplicated code in ConstantDataSequential creation. NFCJustin Bogner2015-12-011-136/+57
| | | | | | | | ConstantDataArray::getImpl and ConstantDataVector::getImpl had a lot of copy pasta in how they handled sequences of constants. Break that out into a couple of simple functions. llvm-svn: 254456
* Fix another infinite loop in Reassociate caused by Constant::isZero().Owen Anderson2015-11-201-0/+10
| | | | | | Not all zero vectors are ConstantDataVector's. llvm-svn: 253723
* Fix a pair of issues that caused an infinite loop in reassociate.Owen Anderson2015-11-201-0/+6
| | | | | | | | Terrifyingly, one of them is a mishandling of floating point vectors in Constant::isZero(). How exactly this issue survived this long is beyond me. llvm-svn: 253655
* Drop prelink support.Rafael Espindola2015-11-171-16/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way prelink used to work was * The compiler decides if a given section only has relocations that are know to point to the same DSO. If so, it names it .data.rel.ro.local<something>. * The static linker puts all of these together. * The prelinker program assigns addresses to each library and resolves the local relocations. There are many problems with this: * It is incompatible with address space randomization. * The information passed by the compiler is redundant. The linker knows if a given relocation is in the same DSO or not. If could sort by that if so desired. * There are newer ways of speeding up DSO (gnu hash for example). * Even if we want to implement this again in the compiler, the previous implementation is pretty broken. It talks about relocations that are "resolved by the static linker". If they are resolved, there are none left for the prelinker. What one needs to track is if an expression will require only dynamic relocations that point to the same DSO. At this point it looks like the prelinker is an historical curiosity. For example, fedora has retired it because it failed to build for two releases (http://pkgs.fedoraproject.org/cgit/prelink.git/commit/?id=eb43100a8331d91c801ee3dcdb0a0bb9babfdc1f) This patch removes support for it. That is, it stops printing the ".local" sections. llvm-svn: 253280
* [IR] Manage TheNoneToken with a std::unique_ptrDavid Majnemer2015-11-161-2/+2
| | | | | | Hopefully, this will make the sanitizer build bots happy. llvm-svn: 253248
* Comment update. NFC.Rafael Espindola2015-11-121-16/+0
| | | | | | | | Fix the library name. Don't duplicate the comment in the .cpp file. Don't repeat the name in the comment. llvm-svn: 252911
* [IR] Add support for empty tokensDavid Majnemer2015-11-111-2/+22
| | | | | | | | | | | | | | When working with tokens, it is often the case that one has instructions which consume a token and produce a new token. Currently, we have no mechanism to represent an initial token state. Instead, we can create a notional "empty token" by inventing a new constant which captures the semantics we would like. This new constant is called ConstantTokenNone and is written textually as "token none". Differential Revision: http://reviews.llvm.org/D14581 llvm-svn: 252811
* [opaque pointer type]: Pass explicit pointee type when building a constant GEP.David Blaikie2015-08-211-5/+8
| | | | | | | | | | Gets a bit tricky in the ValueMapper, of course - not sure if we should just expose a list of explicit types for each Value so that the ValueMapper can be neutral to these special cases (it's OK for things like load, where the explicit type is the result type - but when that's not the case, it means plumbing through another "special" type... ) llvm-svn: 245728
* De-constify pointers to Type since they can't be modified. NFCCraig Topper2015-08-011-8/+8
| | | | | | This was already done in most places a while ago. This just fixes the ones that crept in over time. llvm-svn: 243842
* Devirtualize Constant::replaceUsesOfWithOnConstant.Pete Cooper2015-06-241-57/+82
| | | | | | | | | | | | | | | | | | | | This is part of the work to devirtualize Value. The old pattern was to call replaceUsesOfWithOnConstant which was overridden by subclasses. Those could then call replaceUsesOfWithOnConstantImpl on Constant to handle deleting the current value. To be consistent with other parts of the code, this has been changed so that we call the method on Constant, and that dispatches to an Impl on subclasses. As part of this, it made sense to rename the methods to be more descriptive. The new name is Constant::handleOperandChange, and it requires that all subclasses of Constant implement handleOperandChangeImpl, even if they just throw an error if they shouldn't be called. Reviewed by Duncan Exon Smith. llvm-svn: 240567
* Devirtualize Constant::destroyConstant.Pete Cooper2015-06-231-26/+34
| | | | | | | | | | | | | | | This reorganizes destroyConstant and destroyConstantImpl. Now there is only destroyConstant in Constant itself, while subclasses are required to implement destroyConstantImpl. destroyConstantImpl no longer calls delete but is instead only responsible for removing the constant from any maps in which it is contained. Reviewed by Duncan Exon Smith. llvm-svn: 240471
* Replace all accesses to User::OperandList with getter and setter methods. NFC.Pete Cooper2015-06-121-0/+5
| | | | | | | | | | We don't want anyone to access OperandList directly as its going to be removed and computed instead. This uses getter's and setter's instead in which we can later change the underlying implementation of OperandList. Reviewed by Duncan Exon Smith. llvm-svn: 239620
* Use Op<0> accessor instead of OperandList for Instructions. NFCPete Cooper2015-05-211-1/+1
| | | | | | This is consistent with other uses of the operand list. I'm planning a future commit where this will actually matter. llvm-svn: 237967
* Put GEPOperator member function definition in the appropriate .cpp fileDavid Blaikie2015-05-211-30/+0
| | | | | | Last commit put it in Constants.cpp instead of Operator.cpp llvm-svn: 237960
* [opaque pointer type] Allow gep_type_iterator to work with the pointee type ↵David Blaikie2015-05-211-0/+30
| | | | | | | | | | | from the GEP instruction The raw non-instruction/constant form of this is still relying on being able to access the pointee type from a pointer type - those will be cleaned up later. For now, just focus on the cases where the pointee type is easily accessible. llvm-svn: 237958
* [opaque pointer type] Explicit pointee type for GEPOperator/GEPConstantExpr.David Blaikie2015-05-081-9/+13
| | | | | | | Also a couple of other changes to avoid use of PointerType::getElementType here & there too. llvm-svn: 236799
* Recommit r236670: [opaque pointer type] Pass explicit pointer type through ↵David Blaikie2015-05-071-5/+7
| | | | | | | | | | GEP constant folding"" Clang regressions were caused by more stringent assertion checking introduced by this change. Small fix needed to clang has been committed in r236751. llvm-svn: 236752
* Revert "[opaque pointer type] Pass explicit pointer type through GEP ↵David Blaikie2015-05-061-7/+5
| | | | | | | | | | constant folding" Causes regressions in Clang. Reverting while I investigate. This reverts commit r236670. llvm-svn: 236678
* [opaque pointer type] Pass explicit pointer type through GEP constant foldingDavid Blaikie2015-05-061-5/+7
| | | | llvm-svn: 236670
* IR: Add ConstantFP::getNaN()Tom Stellard2015-04-201-0/+11
| | | | | | This is a wrapper around APFloat::getNaN(). llvm-svn: 235332
* [opaque pointer type] API migration for GEP constant factoriesDavid Blaikie2015-04-021-13/+15
| | | | | | | | | | | | | Require the pointee type to be passed explicitly and assert that it is correct. For now it's possible to pass nullptr here (and I've done so in a few places in this patch) but eventually that will be disallowed once all clients have been updated or removed. It'll be a long road to get all the way there... but if you have the cahnce to update your callers to pass the type explicitly without depending on a pointer's element type, that would be a good thing to do soon and a necessary thing to do eventually. llvm-svn: 233938
* [opaque pointer type] Change GetElementPtrInst::getIndexedType to take the ↵David Blaikie2015-03-301-1/+2
| | | | | | | | | | pointee type This pushes the use of PointerType::getElementType up into several callers - I'll essentially just have to keep pushing that up the stack until I can eliminate every call to it... llvm-svn: 233604
* [opaque pointer type] Start migrating GEP creation to explicitly specify the ↵David Blaikie2015-03-141-6/+8
| | | | | | | | | | | | | | | pointee type I'm just going to migrate these in a pretty ad-hoc & incremental way - providing the backwards compatible API for now, then locally removing it, fixing a few callers, adding it back in and commiting those callers. Rinse, repeat. The assertions should ensure that if I get this wrong we'll find out about it and not just have one giant patch to revert, recommit, revert, recommit, etc. llvm-svn: 232240
* Simplify code. NFC.Benjamin Kramer2015-03-021-4/+2
| | | | llvm-svn: 230948
* Convert push_back loops into append calls.Benjamin Kramer2015-02-281-4/+1
| | | | | | No functionality change intended. llvm-svn: 230849
* Constants.cpp: Only read 32 bits for float.Benjamin Kramer2015-02-201-3/+6
| | | | | | Otherwise we'll discard the wrong half of a uint64_t on big-endian systems. llvm-svn: 230016
* Constants.cpp: getElementAsAPFloat(): Don't handle constant value via host's ↵NAKAMURA Takumi2015-02-201-8/+5
| | | | | | | | float/double, just handle with APInt/APFloat. x87 FPU didn't keep SNAN, but demoted to QNAN. llvm-svn: 230013
* Avoid conversion to float when creating ConstantDataArray/ConstantDataVector.Rafael Espindola2015-02-191-19/+72
| | | | | | Patch by Raoux, Thomas F! llvm-svn: 229864
OpenPOWER on IntegriCloud