summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Constants.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [IR] Implement ↵Craig Topper2017-07-151-19/+67
| | | | | | | | | | | | | | | | | | | Constant::isNegativeZeroValue/isZeroValue/isAllOnesValue/isOneValue/isMinSignedValue for ConstantDataVector without going through getElementAsConstant Summary: Currently these methods call ConstantDataVector::getSplatValue which uses getElementsAsConstant to create a Constant object representing the element value. This method incurs a map lookup to see if we already have created such a Constant before and if not allocates a new Constant object. This patch changes these methods to use getElementAsAPFloat and getElementAsInteger so we can just examine the data values directly. Reviewers: spatel, pcc, dexonsmith, bogner, craig.topper Reviewed By: craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D35040 llvm-svn: 308112
* [IR] Remove unnecessary const_casts from ConstantDataSequential and it's ↵Craig Topper2017-07-111-29/+25
| | | | | | subclasses. llvm-svn: 307666
* [IR] Add Type::isIntOrIntVectorTy(unsigned) similar to the existing ↵Craig Topper2017-07-091-2/+2
| | | | | | isIntegerTy(unsigned), but also works for vectors. llvm-svn: 307492
* [IR] Make use of ↵Craig Topper2017-07-091-4/+4
| | | | | | Type::isPtrOrPtrVectorTy/isIntOrIntVectorTy/isFPOrFPVectorTy to shorten code. NFC llvm-svn: 307491
* [IR] Use CmpInst::isFPPredicate/isIntPredicate in a few other places. NFCCraig Topper2017-07-051-3/+4
| | | | llvm-svn: 307224
* [Constants] Fix copy-pasto in llvm_unreachable message. NFCCraig Topper2017-06-271-1/+1
| | | | llvm-svn: 306456
* [Constants] Use isUIntN/isIntN from MathExtras instead of reimplementing the ↵Craig Topper2017-06-071-9/+2
| | | | | | same code. NFC llvm-svn: 304856
* [Constants] Use APInt::isNullValue/isOneValue/uge to simplify some code and ↵Craig Topper2017-06-071-1/+1
| | | | | | take advantage of APInt optimizations. NFC llvm-svn: 304855
* SimplifyLibCalls: Optimize wcslenMatthias Braun2017-05-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Refactor the strlen optimization code to work for both strlen and wcslen. This especially helps with programs in the wild where people pass L"string"s to const std::wstring& function parameters and the wstring constructor gets inlined. This also fixes a lingerind API problem/bug in getConstantStringInfo() where zeroinitializers would always give you an empty string (without a length) back regardless of the actual length of the initializer which did not work well in the TrimAtNul==false causing the PR mentioned below. Note that the fixed getConstantStringInfo() needed fixes to SelectionDAG memcpy lowering and may lead to some cases for out-of-bounds zeroinitializer accesses not getting optimized anymore. So some code with UB may produce out of bound memory reads now instead of just producing zeros. The refactoring "accidentally" fixes http://llvm.org/PR32124 Differential Revision: https://reviews.llvm.org/D32839 llvm-svn: 303461
* [IR] De-virtualize ~Value to save a vptrReid Kleckner2017-05-181-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Implements PR889 Removing the virtual table pointer from Value saves 1% of RSS when doing LTO of llc on Linux. The impact on time was positive, but too noisy to conclusively say that performance improved. Here is a link to the spreadsheet with the original data: https://docs.google.com/spreadsheets/d/1F4FHir0qYnV0MEp2sYYp_BuvnJgWlWPhWOwZ6LbW7W4/edit?usp=sharing This change makes it invalid to directly delete a Value, User, or Instruction pointer. Instead, such code can be rewritten to a null check and a call Value::deleteValue(). Value objects tend to have their lifetimes managed through iplist, so for the most part, this isn't a big deal. However, there are some places where LLVM deletes values, and those places had to be migrated to deleteValue. I have also created llvm::unique_value, which has a custom deleter, so it can be used in place of std::unique_ptr<Value>. I had to add the "DerivedUser" Deleter escape hatch for MemorySSA, which derives from User outside of lib/IR. Code in IR cannot include MemorySSA headers or call the MemoryAccess object destructors without introducing a circular dependency, so we need some level of indirection. Unfortunately, no class derived from User may have any virtual methods, because adding a virtual method would break User::getHungOffOperands(), which assumes that it can find the use list immediately prior to the User object. I've added a static_assert to the appropriate OperandTraits templates to help people avoid this trap. Reviewers: chandlerc, mehdi_amini, pete, dberlin, george.burgess.iv Reviewed By: chandlerc Subscribers: krytarowski, eraman, george.burgess.iv, mzolotukhin, Prazek, nlewycky, hans, inglorion, pcc, tejohnson, dberlin, llvm-commits Differential Revision: https://reviews.llvm.org/D31261 llvm-svn: 303362
* Suppress all uses of LLVM_END_WITH_NULL. NFC.Serge Guelton2017-05-091-13/+2
| | | | | | | | | Use variadic templates instead of relying on <cstdarg> + sentinel. This enforces better type checking and makes code more readable. Differential Revision: https://reviews.llvm.org/D32541 llvm-svn: 302571
* [Constants] simplify get true/false code; NFCISanjay Patel2017-04-161-18/+10
| | | | llvm-svn: 300424
* [IR] Fix a typo in a comment. NFCCraig Topper2017-04-111-1/+1
| | | | llvm-svn: 299918
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-41/+41
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
* [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
OpenPOWER on IntegriCloud