summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/ValueTracking.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix an ODR violation consisting of two 'struct Query' in the global namespace.Benjamin Kramer2014-09-121-0/+2
| | | | | | Put them in their own anonymous namespaces. Found by GCC's new -Wodr (PR20915). llvm-svn: 217662
* Add additional patterns for @llvm.assume in ValueTrackingHal Finkel2014-09-071-0/+212
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This builds on r217342, which added the infrastructure to compute known bits using assumptions (@llvm.assume calls). That original commit added only a few patterns (to catch common cases related to determining pointer alignment); this change adds several other patterns for simple cases. r217342 contained that, for assume(v & b = a), bits in the mask that are known to be one, we can propagate known bits from the a to v. It also had a known-bits transfer for assume(a = b). This patch adds: assume(~(v & b) = a) : For those bits in the mask that are known to be one, we can propagate inverted known bits from the a to v. assume(v | b = a) : For those bits in b that are known to be zero, we can propagate known bits from the a to v. assume(~(v | b) = a): For those bits in b that are known to be zero, we can propagate inverted known bits from the a to v. assume(v ^ b = a) : For those bits in b that are known to be zero, we can propagate known bits from the a to v. For those bits in b that are known to be one, we can propagate inverted known bits from the a to v. assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can propagate inverted known bits from the a to v. For those bits in b that are known to be one, we can propagate known bits from the a to v. assume(v << c = a) : For those bits in a that are known, we can propagate them to known bits in v shifted to the right by c. assume(~(v << c) = a) : For those bits in a that are known, we can propagate them inverted to known bits in v shifted to the right by c. assume(v >> c = a) : For those bits in a that are known, we can propagate them to known bits in v shifted to the right by c. assume(~(v >> c) = a) : For those bits in a that are known, we can propagate them inverted to known bits in v shifted to the right by c. assume(v >=_s c) where c is non-negative: The sign bit of v is zero assume(v >_s c) where c is at least -1: The sign bit of v is zero assume(v <=_s c) where c is negative: The sign bit of v is one assume(v <_s c) where c is non-positive: The sign bit of v is one assume(v <=_u c): Transfer the known high zero bits assume(v <_u c): Transfer the known high zero bits (if c is know to be a power of 2, transfer one more) A small addition to InstCombine was necessary for some of the test cases. The problem is that when InstCombine was simplifying and, or, etc. it would fail to check the 'do I know all of the bits' condition before checking less specific conditions and would not fully constant-fold the result. I'm not sure how to trigger this aside from using assumptions, so I've just included the change here. llvm-svn: 217343
* Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)Hal Finkel2014-09-071-104/+457
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change, which allows @llvm.assume to be used from within computeKnownBits (and other associated functions in ValueTracking), adds some (optional) parameters to computeKnownBits and friends. These functions now (optionally) take a "context" instruction pointer, an AssumptionTracker pointer, and also a DomTree pointer, and most of the changes are just to pass this new information when it is easily available from InstSimplify, InstCombine, etc. As explained below, the significant conceptual change is that known properties of a value might depend on the control-flow location of the use (because we care that the @llvm.assume dominates the use because assumptions have control-flow dependencies). This means that, when we ask if bits are known in a value, we might get different answers for different uses. The significant changes are all in ValueTracking. Two main changes: First, as with the rest of the code, new parameters need to be passed around. To make this easier, I grouped them into a structure, and I made internal static versions of the relevant functions that take this structure as a parameter. The new code does as you might expect, it looks for @llvm.assume calls that make use of the value we're trying to learn something about (often indirectly), attempts to pattern match that expression, and uses the result if successful. By making use of the AssumptionTracker, the process of finding @llvm.assume calls is not expensive. Part of the structure being passed around inside ValueTracking is a set of already-considered @llvm.assume calls. This is to prevent a query using, for example, the assume(a == b), to recurse on itself. The context and DT params are used to find applicable assumptions. An assumption needs to dominate the context instruction, or come after it deterministically. In this latter case we only handle the specific case where both the assumption and the context instruction are in the same block, and we need to exclude assumptions from being used to simplify their own ephemeral values (those which contribute only to the assumption) because otherwise the assumption would prove its feeding comparison trivial and would be removed. This commit adds the plumbing and the logic for a simple masked-bit propagation (just enough to write a regression test). Future commits add more patterns (and, correspondingly, more regression tests). llvm-svn: 217342
* Make fabs safe to speculatively executeMatt Arsenault2014-08-291-0/+1
| | | | llvm-svn: 216736
* ValueTracking: Figure out more bits when looking at add/subDavid Majnemer2014-08-221-66/+38
| | | | | | | | | Given something like X01XX + X01XX, we know that the result must look like X1XXX. Adapted from a patch by Richard Smith, test-case written by me. llvm-svn: 216250
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-1/+1
| | | | | | needing to mention the size. llvm-svn: 216158
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-181-1/+1
| | | | | | | | 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-1/+1
| | | | | | needing to mention the size. llvm-svn: 215868
* Make use of the align parameter attribute for all pointer argumentsHal Finkel2014-07-221-6/+2
| | | | | | | | | | | | | | | | | | | | We previously supported the align attribute on all (pointer) parameters, but we only used it for byval parameters. However, it is completely consistent at the IR level to treat 'align n' on all pointer parameters as an alignment assumption on the pointer, and now we wll. Specifically, this causes computeKnownBits to use the align attribute on all pointer parameters, not just byval parameters. I've also added an explicit parameter attribute test for this to test/Bitcode/attributes.ll. And I've updated the LangRef to document the align parameter attribute (as it turns out, it was not documented at all previously, although the byval documentation mentioned that it could be used). There are (at least) two benefits to doing this: - It allows enhancing alignment based on the pointer alignment after inlining callees. - It allows simplification of pointer arithmetic. llvm-svn: 213670
* Add a dereferenceable attributeHal Finkel2014-07-181-1/+1
| | | | | | | | | 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
* Teach computeKnownBits to look through addrspacecast.Matt Arsenault2014-07-151-0/+2
| | | | | | This fixes inferring alignment through an addrspacecast. llvm-svn: 213030
* Teach GetUnderlyingObject / BasicAA about addrspacecastMatt Arsenault2014-07-151-1/+2
| | | | llvm-svn: 213025
* Look through addrspacecast in GetPointerBaseWithConstantOffsetMatt Arsenault2014-07-141-1/+2
| | | | llvm-svn: 212999
* Allow isDereferenceablePointer to look through some bitcastsHal Finkel2014-07-101-1/+1
| | | | | | | | | | | | | | | | 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
* fixed typos in commentsSanjay Patel2014-07-061-2/+2
| | | | llvm-svn: 212424
* [ValueTracking] Extend range metadata to call/invokeJingyue Wu2014-06-191-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: With this patch, range metadata can be added to call/invoke including IntrinsicInst. Previously, it could only be added to load. Rename computeKnownBitsLoad to computeKnownBitsFromRangeMetadata because range metadata is not only used by load. Update the language reference to reflect this change. Test Plan: Add several tests in range-2.ll to confirm the verifier is happy with having range metadata on call/invoke. Add two tests in AddOverFlow.ll to confirm annotating range metadata to call/invoke can benefit InstCombine. Reviewers: meheff, nlewycky, reames, hfinkel, eliben Reviewed By: eliben Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D4187 llvm-svn: 211281
* Teach isKnownNonNull that a nonnull return is not null. Add a test for this ↵Nick Lewycky2014-05-201-0/+5
| | | | | | case as well as the case of a nonnull attribute (already handled but not tested). llvm-svn: 209193
* Add 'nonnull', a new parameter and return attribute which indicates that the ↵Nick Lewycky2014-05-201-2/+2
| | | | | | pointer is not null. Instcombine will elide comparisons between these and null. Patch by Luqman Aden! llvm-svn: 209185
* Instead of littering asserts throughout the code after every call toJay Foad2014-05-151-38/+27
| | | | | | | computeKnownBits, consolidate them into one assert at the end of computeKnownBits itself. llvm-svn: 208876
* Rename ComputeMaskedBits to computeKnownBits. "Masked" has beenJay Foad2014-05-141-77/+77
| | | | | | inappropriate since it lost its Mask parameter in r154011. llvm-svn: 208811
* Update the comments for ComputeMaskedBits, which lost its Mask parameterJay Foad2014-05-141-2/+2
| | | | | | in r154011. llvm-svn: 208757
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-151-19/+19
| | | | | | instead of comparing to nullptr. llvm-svn: 206243
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ConstantRange class into the IR library. This isChandler Carruth2014-03-041-1/+1
| | | | | | | | | | a bit surprising, as the class is almost entirely abstracted away from any particular IR, however it encodes the comparsion predicates which mutate ranges as ICmp predicate codes. This is reasonable as they're used for both instructions and constants. Thus, it belongs in the IR library with instructions and constants. llvm-svn: 202838
* [Modules] Move the LLVM IR pattern match header into the IR library, itChandler Carruth2014-03-041-1/+1
| | | | | | obviously is coupled to the IR. llvm-svn: 202818
* [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
* Allow speculating llvm.sqrt, fma and fmuladdMatt Arsenault2014-01-311-0/+6
| | | | | | | | This doesn't set errno, so this should be OK. Also update the documentation to explicitly state that errno are not set. llvm-svn: 200501
* Update optimization passes to handle inalloca argumentsReid Kleckner2014-01-281-4/+5
| | | | | | | | | | | | | | | Summary: I searched Transforms/ and Analysis/ for 'ByVal' and updated those call sites to check for inalloca if appropriate. I added tests for any change that would allow an optimization to fire on inalloca. Reviewers: nlewycky Differential Revision: http://llvm-reviews.chandlerc.com/D2449 llvm-svn: 200281
* Don't speculate loads under ThreadSanitizerKostya Serebryany2013-11-211-1/+3
| | | | | | | | | | | | | | | | | Summary: Don't speculate loads under ThreadSanitizer. This fixes https://code.google.com/p/thread-sanitizer/issues/detail?id=40 Also discussed here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-November/067929.html Reviewers: chandlerc Reviewed By: chandlerc CC: llvm-commits, dvyukov Differential Revision: http://llvm-reviews.chandlerc.com/D2227 llvm-svn: 195324
* Remove x86_sse42_crc32_64_8 intrinsic. It has no functional difference from ↵Craig Topper2013-10-151-1/+0
| | | | | | x86_sse42_crc32_32_8 and was not mapped to a clang builtin. I'm not even sure why this form of the instruction is even called out explicitly in the docs. Also add AutoUpgrade support to convert it into the other intrinsic with appropriate trunc and zext. llvm-svn: 192672
* Teach MemoryBuiltins and InstructionSimplify that operator new never returns ↵Benjamin Kramer2013-09-241-1/+7
| | | | | | | | | | | | NULL. This is safe per C++11 18.6.1.1p3: [operator new returns] a non-null pointer to suitably aligned storage (3.7.4), or else throw a bad_alloc exception. This requirement is binding on a replacement version of this function. Brings us a tiny bit closer to eliminating more vector push_backs. llvm-svn: 191310
* Fix assert with GEP ptr vector indexing structsMatt Arsenault2013-08-191-2/+12
| | | | | | | | Also fix it calculating the wrong value. The struct index is not a ConstantInt, so it was being interpreted as an array index. llvm-svn: 188713
* Teach ValueTracking about address spacesMatt Arsenault2013-08-101-8/+12
| | | | llvm-svn: 188140
* isKnownToBeAPowerOfTwo: Strengthen isKnownToBeAPowerOfTwo's analysis on add ↵David Majnemer2013-07-301-16/+30
| | | | | | | | | instructions Call into ComputeMaskedBits to figure out which bits are set on both add operands and determine if the value is a power-of-two-or-zero or not. llvm-svn: 187445
* Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector ↵Craig Topper2013-07-111-1/+1
| | | | | | size. llvm-svn: 186098
* ValueTracking: Fix bugs in isKnownToBeAPowerOfTwoDavid Majnemer2013-07-091-6/+4
| | | | | | | (add nsw x, (and x, y)) isn't a power of two if x is zero, it's zero (add nsw x, (xor x, y)) isn't a power of two if y has bits set that aren't set in x llvm-svn: 185954
* isKnownToBeAPowerOfTwo: Fix a typo in a commentDavid Majnemer2013-07-061-1/+1
| | | | llvm-svn: 185748
* ValueTracking: Teach isKnownToBeAPowerOfTwo about (ADD X, (XOR X, Y)) where ↵David Majnemer2013-06-291-10/+18
| | | | | | | | | X is a power of two This allows us to simplify urem instructions involving the add+xor to turn into simpler math. llvm-svn: 185272
* Replace Count{Leading,Trailing}Zeros_{32,64} with count{Leading,Trailing}Zeros.Michael J. Spencer2013-05-241-6/+6
| | | | llvm-svn: 182680
* isKnownToBeAPowerOfTwo: (X & Y) + Y is a power of 2 or zero if y is also.David Majnemer2013-05-181-0/+11
| | | | | | | This is useful if something that looks like (x & (1 << y)) ? 64 : 32 is the divisor in a modulo operation. llvm-svn: 182200
* Check whether a pointer is non-null (isKnownNonNull) in isKnownNonZero.Manman Ren2013-03-181-0/+2
| | | | | | | | This handles the case where we have an inbounds GEP with alloca as the pointer. This fixes the regression in PR12750 and rdar://13286434. Note that we can also fix this by handling some GEP cases in isKnownNonNull. llvm-svn: 177321
* Use dyn_cast instead of isa && cast. No functionality change.Jakub Staszak2013-03-061-4/+4
| | | | llvm-svn: 176537
* Move isKnownNonNull out of AliasAnalysis.h and into ValueTracking.cpp sinceDan Gohman2013-01-311-0/+16
| | | | | | | it isn't really an AliasAnalysis concept, and ValueTracking has similar things that it could plausibly share code with some day. llvm-svn: 174027
* Change GetPointerBaseWithConstantOffset's DataLayout argument from aDan Gohman2013-01-311-3/+5
| | | | | | | reference to a pointer, so that it can handle the case where DataLayout is not available and behave conservatively. llvm-svn: 174024
* Remove redundant 'llvm::' qualificationsDmitri Gribenko2013-01-131-1/+1
| | | | llvm-svn: 172358
* 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
* reimplement GetPointerBaseWithConstantOffset().Nuno Lopes2012-12-311-31/+21
| | | | | | | The new code is an improved copy of the code I deleted from Analysis/Loads.cpp. One less compute-constant-gep-offset implementation. yay :) llvm-svn: 171326
* Remove trailing whitespace.Craig Topper2012-12-221-94/+94
| | | | llvm-svn: 170991
* Fix a bug that was found by building clang with -fsanitize.Nadav Rotem2012-12-191-1/+6
| | | | | | | | | I introduced it in r166785. PR14291. If TD is unavailable use getScalarSizeInBits, but don't optimize pointers or vectors of pointers. llvm-svn: 170586
* Fix a crash in ValueTracking on vectors of pointers. Nadav Rotem2012-12-141-1/+1
| | | | llvm-svn: 170240
OpenPOWER on IntegriCloud