summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Constants.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* IR: Properly return nullptr when getAggregateElement is out-of-boundsDavid Majnemer2015-02-161-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
* Reapply "LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP ↵Benjamin Kramer2014-12-061-10/+8
| | | | | | | | DenseMaps." This reapplies r223478 with a fix for 32 bit targets. llvm-svn: 223586
* Reformat.NAKAMURA Takumi2014-12-061-3/+3
| | | | llvm-svn: 223580
* Revert "LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP ↵Benjamin Kramer2014-12-061-9/+10
| | | | | | | | | DenseMaps." Somehow made DenseMap probe on forever on 32 bit machines. This reverts commit r223478. llvm-svn: 223546
* LLVMContext: Store APInt/APFloat directly into the ConstantInt/FP DenseMaps.Benjamin Kramer2014-12-051-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
* Revert "unique_ptrify LLVMContextImpl::CAZConstants"David Blaikie2014-11-251-4/+4
| | | | | | | | Missed the complexities of how these elements are destroyed. This reverts commit r222714. llvm-svn: 222715
* unique_ptrify LLVMContextImpl::CAZConstantsDavid Blaikie2014-11-251-4/+4
| | | | llvm-svn: 222714
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-191-2/+2
| | | | | | | | | | | | | pair<iterator, bool> This is to be consistent with StringSet and ultimately with the standard library's associative container insert function. This lead to updating SmallSet::insert to return pair<iterator, bool>, and then to update SmallPtrSet::insert to return pair<iterator, bool>, and then to update all the existing users of those functions... llvm-svn: 222334
* Remove StringMap::GetOrCreateValue in favor of StringMap::insertDavid Blaikie2014-11-191-5/+7
| | | | | | | | | | | | | | Having two ways to do this doesn't seem terribly helpful and consistently using the insert version (which we already has) seems like it'll make the code easier to understand to anyone working with standard data structures. (I also updated many references to the Entry's key and value to use first() and second instead of getKey{Data,Length,} and get/setValue - for similar consistency) Also removes the GetOrCreateValue functions so there's less surface area to StringMap to fix/improve/change/accommodate move semantics, etc. llvm-svn: 222319
* Use nullptr instead of NULL for variadic sentinelsReid Kleckner2014-11-131-2/+2
| | | | | | | | | | Windows defines NULL to 0, which when used as an argument to a variadic function, is not a null pointer constant. As a result, Clang's -Wsentinel fires on this code. Using '0' would be wrong on most 64-bit platforms, but both MSVC and Clang make it work on Windows. Sidestep the issue with nullptr. llvm-svn: 221940
* Simplify creation of a bunch of ArrayRefs by using None, makeArrayRef or ↵Craig Topper2014-08-271-1/+1
| | | | | | just letting them be implicitly created. llvm-svn: 216525
* InstCombine: sub nsw %x, C -> add nsw %x, -C if C isn't INT_MINDavid Majnemer2014-08-221-0/+23
| | | | | | We can preserve nsw during this transform if -C won't overflow. llvm-svn: 216269
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-1/+1
| | | | | | needing to mention the size. llvm-svn: 216158
* IR: Fix ConstantExpr::replaceUsesOfWithOnConstant()Duncan P. N. Exon Smith2014-08-191-50/+13
| | | | | | | | | | | | | Change `ConstantExpr` to follow the model the other constants are using: only malloc a replacement if it's going to be used. This fixes a subtle bug where if an API user had used `ConstantExpr::get()` already to create the replacement but hadn't given it any users, we'd delete the replacement. This relies on r216015 to thread `OnlyIfReduced` through `ConstantExpr::getWithOperands()`. llvm-svn: 216016
* IR: Thread OnlyIfReduced through ConstantExpr::getWithOperands()Duncan P. N. Exon Smith2014-08-191-74/+136
| | | | | | | | | | | | | | In order to change `ConstantExpr::replaceUsesOfWithOnConstant()` to work like other constants (e.g., using `ConstantArray::getImpl()`), thread `OnlyIfReduced` through as necessary. When `OnlyIfReduced` is false, there's no functionality change. When it's true, if there's no constant folding or type changes `nullptr` is returned instead of the new constant. `ConstantExpr::replaceUsesOfWithOnConstant()` will be updated to use the "true" version in a follow-up commit. llvm-svn: 216015
* IR: De-duplicate code for replacing operands in placeDuncan P. N. Exon Smith2014-08-191-69/+11
| | | | | | | This is non-trivial and sits in three places. Move it to ConstantUniqueMap. llvm-svn: 216007
* Reapply r215966, r215965, r215964, r215963, r215960, r215959, r215958, and ↵Duncan P. N. Exon Smith2014-08-191-110/+179
| | | | | | | | | | | | r215957 This reverts commit r215981, which reverted the above commits because MSVC std::equal asserts on nullptr iterators, and thes commits introduced an `ArrayRef::equals()` on empty ArrayRefs. ArrayRef was changed not to use std::equal in r215986. llvm-svn: 215987
* Reverting r215966, r215965, r215964, r215963, r215960, r215959, r215958, and ↵Aaron Ballman2014-08-191-179/+110
| | | | | | r215957 (these commits all rely on previous commits) due to build breakage. These commits cause failed assertions when testing Clang using MSVC 2013. The asserts are triggered from the std::equal call within ArrayRef::equals due to being passed invalid input (ArrayRef.begin() is returning a nullptr which is problematic). llvm-svn: 215981
* IR: Reduce RAUW traffic in ConstantVectorDuncan P. N. Exon Smith2014-08-191-3/+27
| | | | | | | | | Avoid creating a new `ConstantVector` on an RAUW of one of its members. This reduces RAUW traffic on any containing constant. This is part of PR20515. llvm-svn: 215966
* IR: Fix ConstantArray::replaceUsesOfWithOnConstant()Duncan P. N. Exon Smith2014-08-191-0/+6
| | | | | | | | Previously, `ConstantArray::replaceUsesOfWithOnConstant()` neglected to check whether it becomes a `ConstantDataArray`. Call `ConstantArray::getImpl()` to check for that. llvm-svn: 215965
* IR: Factor out replaceUsesOfWithOnConstantImpl(), NFCDuncan P. N. Exon Smith2014-08-191-94/+80
| | | | | | | Factor out common code, and take advantage of the new function to add early returns to the callers. llvm-svn: 215964
* IR: Split up Constant{Array,Vector}::get(), NFCDuncan P. N. Exon Smith2014-08-191-4/+13
| | | | | | | | Introduce `getImpl()` that tries the simplification logic from `get()` and then gives up. This allows the logic to be reused elsewhere in a follow-up commit. llvm-svn: 215963
* IR: Reduce RAUW traffic in ConstantExprDuncan P. N. Exon Smith2014-08-191-0/+44
| | | | | | | | | | | | | Avoid RAUW-ing `ConstantExpr` when an operand changes unless the new `ConstantExpr` already has users. This prevents the RAUW from rippling up the expression tree unnecessarily. This commit indirectly adds test coverage for r215953 (this is how I came across the bug). This is part of PR20515. llvm-svn: 215960
* IR: Rewrite ConstantUniqueMapDuncan P. N. Exon Smith2014-08-191-12/+12
| | | | | | | | | | | | | | | | | | | | | Rewrite `ConstantUniqueMap` to be more similar to `ConstantAggrUniqueMap`. - Use a `DenseMap` with custom MapInfo instead of a `std::map` with linear lookups and deletion. - Don't waste memory explicitly storing (heavyweight) keys. Only `ConstantExpr` and `InlineAsm` actually use this data structure, so I also updated them to use it. This code cleanup is a precursor to reducing RAUW traffic on `ConstantExpr` -- I felt badly adding a new (linear) call to `ConstantUniqueMap::FindExistingKey`, so this designs away the concern. A follow-up commit will transition the users of `ConstantAggrUniqueMap` over. llvm-svn: 215957
OpenPOWER on IntegriCloud