aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/IR/Constants.cpp
AgeCommit message (Collapse)AuthorFilesLines
2016-08-29[Constant] remove fdiv and frem from canTrap()Sanjay Patel1-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
2016-06-26Apply clang-tidy's modernize-loop-convert to most of lib/IR.Benjamin Kramer1-2/+2
Only minor manual fixes. No functionality change intended. llvm-svn: 273813
2016-06-12[IR] Require ArrayRef of 'uint32_t' instead of 'int' for the mask argument ↵Craig Topper1-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
2016-05-29[IR] Teach the ArrayRef<int> form of IRBuilder::CreateShuffleVector to use ↵Craig Topper1-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
2016-05-18fix formatting; NFCSanjay Patel1-6/+3
llvm-svn: 269990
2016-05-15Vector GEP - fixed a crash on InstSimplify Pass.Elena Demikhovsky1-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
2016-04-29clean up documentation comments; NFCSanjay Patel1-110/+14
llvm-svn: 268122
2016-04-18[NFC] Header cleanupMehdi Amini1-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
2016-04-05IR: Introduce ConstantAggregate, NFCDuncan P. N. Exon Smith1-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
2016-04-05IR: Add missing assertion for ConstantVector::ConstantVectorDuncan P. N. Exon Smith1-0/+2
Use the same assertion as ConstantArray. Vectors should have the right number of elements. llvm-svn: 265463
2016-02-21IR: Add ConstantData, for operand-less ConstantsDuncan P. N. Exon Smith1-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
2016-02-10Simplify handleOperandChangeImpl() removing last argument (NFC)Mehdi Amini1-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
2016-01-19[opaque pointer types] [NFC] GEP: replace get(Pointer)ElementType uses with ↵Eduard Burtescu1-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
2015-12-15[IR] Add classof for GetElementPtrConstantExpr, CompareConstantExpr, ↵Craig Topper1-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
2015-12-15Use CmpInst::Predicate instead of 'unsigned short' in some places. NFCCraig Topper1-1/+1
llvm-svn: 255623
2015-12-09IR: Make ConstantDataArray::getFP actually return a ConstantDataArrayJustin Bogner1-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
2015-12-08IR: Allow vectors of halfs to be ConstantDataVectorsJustin Bogner1-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
2015-12-01IR: Clean up some duplicated code in ConstantDataSequential creation. NFCJustin Bogner1-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
2015-11-20Fix another infinite loop in Reassociate caused by Constant::isZero().Owen Anderson1-0/+10
Not all zero vectors are ConstantDataVector's. llvm-svn: 253723
2015-11-20Fix a pair of issues that caused an infinite loop in reassociate.Owen Anderson1-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
2015-11-17Drop prelink support.Rafael Espindola1-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
2015-11-16[IR] Manage TheNoneToken with a std::unique_ptrDavid Majnemer1-2/+2
Hopefully, this will make the sanitizer build bots happy. llvm-svn: 253248
2015-11-12Comment update. NFC.Rafael Espindola1-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
2015-11-11[IR] Add support for empty tokensDavid Majnemer1-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
2015-08-21[opaque pointer type]: Pass explicit pointee type when building a constant GEP.David Blaikie1-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
2015-08-01De-constify pointers to Type since they can't be modified. NFCCraig Topper1-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
2015-06-24Devirtualize Constant::replaceUsesOfWithOnConstant.Pete Cooper1-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
2015-06-23Devirtualize Constant::destroyConstant.Pete Cooper1-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
2015-06-12Replace all accesses to User::OperandList with getter and setter methods. NFC.Pete Cooper1-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
2015-05-21Use Op<0> accessor instead of OperandList for Instructions. NFCPete Cooper1-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
2015-05-21Put GEPOperator member function definition in the appropriate .cpp fileDavid Blaikie1-30/+0
Last commit put it in Constants.cpp instead of Operator.cpp llvm-svn: 237960
2015-05-21[opaque pointer type] Allow gep_type_iterator to work with the pointee type ↵David Blaikie1-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
2015-05-08[opaque pointer type] Explicit pointee type for GEPOperator/GEPConstantExpr.David Blaikie1-9/+13
Also a couple of other changes to avoid use of PointerType::getElementType here & there too. llvm-svn: 236799
2015-05-07Recommit r236670: [opaque pointer type] Pass explicit pointer type through ↵David Blaikie1-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
2015-05-06Revert "[opaque pointer type] Pass explicit pointer type through GEP ↵David Blaikie1-7/+5
constant folding" Causes regressions in Clang. Reverting while I investigate. This reverts commit r236670. llvm-svn: 236678
2015-05-06[opaque pointer type] Pass explicit pointer type through GEP constant foldingDavid Blaikie1-5/+7
llvm-svn: 236670
2015-04-20IR: Add ConstantFP::getNaN()Tom Stellard1-0/+11
This is a wrapper around APFloat::getNaN(). llvm-svn: 235332
2015-04-02[opaque pointer type] API migration for GEP constant factoriesDavid Blaikie1-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
2015-03-30[opaque pointer type] Change GetElementPtrInst::getIndexedType to take the ↵David Blaikie1-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
2015-03-14[opaque pointer type] Start migrating GEP creation to explicitly specify the ↵David Blaikie1-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
2015-03-02Simplify code. NFC.Benjamin Kramer1-4/+2
llvm-svn: 230948
2015-02-28Convert push_back loops into append calls.Benjamin Kramer1-4/+1
No functionality change intended. llvm-svn: 230849
2015-02-20Constants.cpp: Only read 32 bits for float.Benjamin Kramer1-3/+6
Otherwise we'll discard the wrong half of a uint64_t on big-endian systems. llvm-svn: 230016
2015-02-20Constants.cpp: getElementAsAPFloat(): Don't handle constant value via host's ↵NAKAMURA Takumi1-8/+5
float/double, just handle with APInt/APFloat. x87 FPU didn't keep SNAN, but demoted to QNAN. llvm-svn: 230013
2015-02-19Avoid conversion to float when creating ConstantDataArray/ConstantDataVector.Rafael Espindola1-19/+72
Patch by Raoux, Thomas F! llvm-svn: 229864
2015-02-16IR: Properly return nullptr when getAggregateElement is out-of-boundsDavid Majnemer1-4/+19
We didn't properly handle the out-of-bounds case for ConstantAggregateZero and UndefValue. This would manifest as a crash when the constant folder was asked to fold a load of a constant global whose struct type has no operands. This fixes PR22595. llvm-svn: 229352
2014-12-06Reapply "LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP ↵Benjamin Kramer1-10/+8
DenseMaps." This reapplies r223478 with a fix for 32 bit targets. llvm-svn: 223586
2014-12-06Reformat.NAKAMURA Takumi1-3/+3
llvm-svn: 223580
2014-12-06Revert "LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP ↵Benjamin Kramer1-9/+10
DenseMaps." Somehow made DenseMap probe on forever on 32 bit machines. This reverts commit r223478. llvm-svn: 223546
2014-12-05LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP DenseMaps.Benjamin Kramer1-10/+9
Required some APInt massaging to get proper empty/tombstone values. Apart from making the code a bit simpler this also reduces the bucket size of the ConstantInt map from 32 to 24 bytes. llvm-svn: 223478
generated by cgit v1.1 at 2025-10-14 12:55:36 +0000