summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Value.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* IR: Cleanup comments for Value, User, and MDNodeDuncan P. N. Exon Smith2014-10-151-26/+4
| | | | | | | | | | | | | A follow-up commit will modify the memory-layout of `Value`, `User`, and `MDNode`. First fix the comments to be doxygen-friendly (and to follow the coding standards). - Use "\brief" instead of "repeatedName -". - Add a brief intro where it was missing. - Remove duplicated comments from source files (and a couple of noisy/trivial comments altogether). llvm-svn: 219844
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-2/+2
| | | | | | needing to mention the size. llvm-svn: 216158
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-181-2/+2
| | | | | | | | avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-171-2/+2
| | | | | | needing to mention the size. llvm-svn: 215868
* IR: Add Value::reverseUseList()Duncan P. N. Exon Smith2014-08-011-0/+19
| | | | | | I'm going to use this to improve `verify-uselistorder`. Part of PR5680. llvm-svn: 214594
* Handle AddrSpaceCast in stripAndAccumulateInBoundsConstantOffsetsHal Finkel2014-07-191-1/+2
| | | | | | | | All of the other similar functions in that part of the file look through addrspacecast in addition to bitcast, and I see no reason why stripAndAccumulateInBoundsConstantOffsets shouldn't do so also. llvm-svn: 213449
* Make Value::isDereferenceablePointer handle offsets to pointer types with ↵Hal Finkel2014-07-191-0/+21
| | | | | | | | | | | | | | | | | | dereferenceable attributes When we have a parameter (or call site return) with a dereferenceable attribute, it can specify the size of an array pointed to by that parameter. If we have a value for which we can accumulate a constant offset to such a parameter, then we can use that offset in a direct comparison with the size specified by the dereferenceable attribute. This enables us to handle cases like this: int foo(int a[static 3]) { return a[2]; /* this is always dereferenceable */ } llvm-svn: 213447
* Add a dereferenceable attributeHal Finkel2014-07-181-3/+24
| | | | | | | | | This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
* Look through addrspacecast when checking isDereferenceablePointerMatt Arsenault2014-07-141-0/+3
| | | | llvm-svn: 212971
* Fix isDereferenceablePointer not to try to take the size of an unsized type.Hal Finkel2014-07-101-1/+2
| | | | | | I'll add a test-case shortly. llvm-svn: 212687
* Allow isDereferenceablePointer to look through some bitcastsHal Finkel2014-07-101-8/+23
| | | | | | | | | | | | | | | | isDereferenceablePointer should not give up upon encountering any bitcast. If we're casting from a pointer to a larger type to a pointer to a small type, we can continue by examining the bitcast's operand. This missing capability was noted in a comment in the function. In order for this to work, isDereferenceablePointer now takes an optional DataLayout pointer (essentially all callers already had such a pointer available). Most code uses isDereferenceablePointer though isSafeToSpeculativelyExecute (which already took an optional DataLayout pointer), and to enable the LICM test case, LICM needs to actually provide its DL pointer to isSafeToSpeculativelyExecute (which it was not doing previously). llvm-svn: 212686
* Convert StringMapEntry::Create to use StringRef instead of start/end ↵Craig Topper2014-06-111-1/+1
| | | | | | pointers. Simpliies all in tree call sites. No functional change. llvm-svn: 210638
* Reorder Value and User fields to save 8 bytes of padding on 64-bitReid Kleckner2014-06-091-4/+3
| | | | | | | | Reviewered by: rafael Differential Revision: http://reviews.llvm.org/D4073 llvm-svn: 210501
* Allow alias to point to an arbitrary ConstantExpr.Rafael Espindola2014-06-031-25/+0
| | | | | | | | | | | | | | | | | | | | | This patch changes GlobalAlias to point to an arbitrary ConstantExpr and it is up to MC (or the system assembler) to decide if that expression is valid or not. This reduces our ability to diagnose invalid uses and how early we can spot them, but it also lets us do things like @test5 = alias inttoptr(i32 sub (i32 ptrtoint (i32* @test2 to i32), i32 ptrtoint (i32* @bar to i32)) to i32*) An important implication of this patch is that the notion of aliased global doesn't exist any more. The alias has to encode the information needed to access it in its metadata (linkage, visibility, type, etc). Another consequence to notice is that getSection has to return a "const char *". It could return a NullTerminatedStringRef if there was such a thing, but when that was proposed the decision was to just uses "const char*" for that. llvm-svn: 210062
* Fix a warning in builds without asserts.Rafael Espindola2014-05-161-2/+1
| | | | llvm-svn: 209012
* Fix most of PR10367.Rafael Espindola2014-05-161-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the design of GlobalAlias so that it doesn't take a ConstantExpr anymore. It now points directly to a GlobalObject, but its type is independent of the aliasee type. To avoid changing all alias related tests in this patches, I kept the common syntax @foo = alias i32* @bar to mean the same as now. The cases that used to use cast now use the more general syntax @foo = alias i16, i32* @bar. Note that GlobalAlias now behaves a bit more like GlobalVariable. We know that its type is always a pointer, so we omit the '*'. For the bitcode, a nice surprise is that we were writing both identical types already, so the format change is minimal. Auto upgrade is handled by looking through the casts and no new fields are needed for now. New bitcode will simply have different types for Alias and Aliasee. One last interesting point in the patch is that replaceAllUsesWith becomes smart enough to avoid putting a ConstantExpr in the aliasee. This seems better than checking and updating every caller. A followup patch will delete getAliasedGlobal now that it is redundant. Another patch will add support for an explicit offset. llvm-svn: 209007
* Assert that we don't RAUW a Constant with a ConstantExpr that contains it.Rafael Espindola2014-05-131-1/+36
| | | | | | | | We already had an assert for foo->RAUW(foo), but not for something like foo->RAUW(GEP(foo)) and would go in an infinite loop trying to apply the replacement. llvm-svn: 208663
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-151-2/+2
| | | | | | instead of comparing to nullptr. llvm-svn: 206252
* [C++11] More 'nullptr' conversion or in some cases just using a boolean ↵Craig Topper2014-04-091-9/+9
| | | | | | check instead of comparing to nullptr. llvm-svn: 205831
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
* [Modules] Move the LeakDetector header into the IR library where theChandler Carruth2014-03-041-1/+1
| | | | | | | | | | | source file had already been moved. Also move the unittest into the IR unittest library. This may seem an odd thing to put in the IR library but we only really use this with instructions and it needs the LLVM context to work, so it is intrinsically tied to the IR library. llvm-svn: 202842
* [Modules] Move ValueHandle into the IR library where Value itself lives.Chandler Carruth2014-03-041-1/+1
| | | | | | | | | | | Move the test for this class into the IR unittests as well. This uncovers that ValueMap too is in the IR library. Ironically, the unittest for ValueMap is useless in the Support library (honestly, so was the ValueHandle test) and so it already lives in the IR unittests. Mmmm, tasty layering. llvm-svn: 202821
* [Modules] Move GetElementPtrTypeIterator into the IR library. As itsChandler Carruth2014-03-041-1/+1
| | | | | | | | | name might indicate, it is an iterator over the types in an instruction in the IR.... You see where this is going. Another step of modularizing the support library. llvm-svn: 202815
* Make it explicit that nulls are not allowed in names.Rafael Espindola2013-11-191-0/+2
| | | | | | | | | | The object files we support use null terminated strings, so there is no way to support these. This patch adds an assert to catch bad API use and an error check in the .ll parser. llvm-svn: 195155
* [weak vtables] Remove a bunch of weak vtablesJuergen Ributzka2013-11-191-6/+2
| | | | | | | | | | | | This patch removes most of the trivial cases of weak vtables by pinning them to a single object file. The memory leaks in this version have been fixed. Thanks Alexey for pointing them out. Differential Revision: http://llvm-reviews.chandlerc.com/D2068 Reviewed by Andy llvm-svn: 195064
* Revert r194865 and r194874.Alexey Samsonov2013-11-181-2/+6
| | | | | | | | | | | | This change is incorrect. If you delete virtual destructor of both a base class and a subclass, then the following code: Base *foo = new Child(); delete foo; will not cause the destructor for members of Child class. As a result, I observe plently of memory leaks. Notable examples I investigated are: ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl. llvm-svn: 194997
* [weak vtables] Remove a bunch of weak vtablesJuergen Ributzka2013-11-151-6/+2
| | | | | | | | | | | This patch removes most of the trivial cases of weak vtables by pinning them to a single object file. Differential Revision: http://llvm-reviews.chandlerc.com/D2068 Reviewed by Andy llvm-svn: 194865
* Add addrspacecast instruction.Matt Arsenault2013-11-151-1/+2
| | | | | | Patch by Michele Scandale! llvm-svn: 194760
* Fix a bug where we would corrupt the offset when evaluatingChandler Carruth2013-08-251-1/+3
| | | | | | | | | | | a non-constant GEP. I don't have any test case that demonstrates this, Nadav (indirectly) pointed this out in code review. I'm not sure how possible it is to contrive a test case for the current users of this code that triggers the bad issue sadly. llvm-svn: 189188
* Add a new helper method to Value to strip in-bounds constant offsets ofChandler Carruth2013-08-221-0/+34
| | | | | | | | | | | pointers, but accumulate the offset into an APInt in the process of stripping it. This is a pretty handy thing to have, such as when trying to determine if two pointers are at some constant relative offset. I'll be committing a patch shortly to use it for exactly that purpose. llvm-svn: 189000
* Speed up Value::isUsedInBasicBlock() for long use lists.Jakob Stoklund Olesen2013-05-141-14/+13
| | | | | | | | | | | | | | | | This is expanding Ben's original heuristic for short basic blocks to also work for longer basic blocks and huge use lists. Scan the basic block and the use list in parallel, terminating the search when the shorter list ends. In almost all cases, either the basic block or the use list is short, and the function returns quickly. In one crazy test case with very long use chains, CodeGenPrepare runs 400x faster. When compiling ARMDisassembler.cpp it is 5x faster. <rdar://problem/13840497> llvm-svn: 181851
* Fix const merging when an alias of a const is llvm.used.Rafael Espindola2013-05-061-1/+7
| | | | | | | We used to disable constant merging not only if a constant is llvm.used, but also if an alias of a constant is llvm.used. This change fixes that. llvm-svn: 181175
* Fix a disconcerting bug in Value::isUsedInBasicBlock, which gave wrong ↵Benjamin Kramer2013-04-121-1/+1
| | | | | | | | answers for blocks larger than 3 instrs. Also add a unit test. PR15727. llvm-svn: 179370
* Cache the result of Function::getIntrinsicID() in a DenseMap attached to the ↵Michael Ilseman2013-03-011-3/+6
| | | | | | | | | | LLVMContext. This reduces the time actually spent doing string to ID conversion and shows a 10% improvement in compile time for a particularly bad case that involves ARM Neon intrinsics (these have many overloads). Patch by Jean-Luc Duprat! llvm-svn: 176365
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-9/+9
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Rename VMCore directory to IR.Chandler Carruth2013-01-021-0/+698
Aside from moving the actual files, this patch only updates the build system and the source file comments under lib/... that are relevant. I'll be updating other docs and other files in smaller subsequnet commits. While I've tried to test this, but it is entirely possible that there will still be some build system fallout. Also, note that I've not changed the library name itself: libLLVMCore.a is still the library name. I'd be interested in others' opinions about whether we should rename this as well (I think we should, just not sure what it might break) llvm-svn: 171359
OpenPOWER on IntegriCloud