summaryrefslogtreecommitdiffstats
path: root/llvm/test/Analysis/ValueTracking
Commit message (Collapse)AuthorAgeFilesLines
* [ValueTracking] Pointer is known nonnull after load/storeDanila Kutenin2019-12-111-8/+3
| | | | | | | | | | | If the pointer was loaded/stored before the null check, the check is redundant and can be removed. For now the optimizers do not remove the nullptr check, see https://gcc.godbolt.org/z/H2r5GG. The patch allows to use more nonnull constraints. Also, it found one more optimization in some PowerPC test. This is my first llvm review, I am free to any comments. Differential Revision: https://reviews.llvm.org/D71177
* [ValueTracking] Add tests for non-null check after load/store; NFCDanila Kutenin2019-12-111-17/+110
| | | | Tests for D71177.
* Autogenerate test/Analysis/ValueTracking/non-negative-phi-bits.ll testRoman Lebedev2019-12-021-1/+1
| | | | Forgot to stage this change into 0f22e783a038b6983f0fe161eef6cf2add3a4156 commit.
* [IR][Verifier] Allow IntToPtrInst to be !dereferenceableRyan Taylor2019-07-231-0/+8
| | | | | | | | | | | | | | | | | Summary: Allow IntToPtrInst to carry !dereferenceable metadata tag. This is valid since !dereferenceable can be only be applied to pointer type values. Change-Id: If8a6e3c616f073d51eaff52ab74535c29ed497b4 Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64954 llvm-svn: 366826
* Basic codegen for MTE stack tagging.Evgeniy Stepanov2019-07-171-0/+16
| | | | | | | | | | | | Implement IR intrinsics for stack tagging. Generated code is very unoptimized for now. Two special intrinsics, llvm.aarch64.irg.sp and llvm.aarch64.tagp are used to implement a tagged stack frame pointer in a virtual register. Differential Revision: https://reviews.llvm.org/D64172 llvm-svn: 366360
* Teach ValueTracking that aarch64.irg result aliases its input.Evgeniy Stepanov2019-07-031-0/+18
| | | | | | | | | | | | Reviewers: javed.absar, olista01 Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64103 llvm-svn: 365079
* [SimplifyCFG] Added condition assumption for unreachable blocksDavid Bolvansky2019-05-251-0/+2
| | | | | | | | | | | | | | | | Summary: PR41688 Reviewers: spatel, efriedma, craig.topper, hfinkel, reames Reviewed By: hfinkel Subscribers: javed.absar, dmgreen, fhahn, hfinkel, reames, nikic, lebedev.ri, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61409 llvm-svn: 361707
* [NFC] Update test checksDavid Bolvansky2019-05-251-0/+1
| | | | llvm-svn: 361695
* [ValueTracking] Adjust comment in testMichael Ferguson2019-01-071-1/+2
| | | | | | Adjusts a comment in this test to verify commit access. llvm-svn: 350569
* [ValueTracking] Fix a misuse of APInt in GetPointerBaseWithConstantOffsetFlorian Hahn2019-01-041-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GetPointerBaseWithConstantOffset include this code, where ByteOffset and GEPOffset are both of type llvm::APInt : ByteOffset += GEPOffset.getSExtValue(); The problem with this line is that getSExtValue() returns an int64_t, but the += matches an overload for uint64_t. The problem is that the resulting APInt is no longer considered to be signed. That in turn causes assertion failures later on if the relevant pointer type is > 64 bits in width and the GEPOffset was negative. Changing it to ByteOffset += GEPOffset.sextOrTrunc(ByteOffset.getBitWidth()); resolves the issue and explicitly performs the sign-extending or truncation. Additionally, instead of asserting later if the result is > 64 bits, it breaks out of the loop in that case. See also https://reviews.llvm.org/D24729 https://reviews.llvm.org/D24772 This commit must be merged after D38662 in order for the test to pass. Patch by Michael Ferguson <mpfergu@gmail.com>. Reviewers: reames, sanjoy, hfinkel Reviewed By: hfinkel Differential Revision: https://reviews.llvm.org/D38501 llvm-svn: 350395
* InstCombine: move hasOneUse check to the top of foldICmpAddConstantTim Northover2018-09-101-1/+1
| | | | | | | | | | | | There were two combines not covered by the check before now, neither of which actually differed from normal in the benefit analysis. The most recent seems to be because it was just added at the top of the function (naturally). The older is from way back in 2008 (r46687) when we just didn't put those checks in so routinely, and has been diligently maintained since. llvm-svn: 341831
* [InstCombine] Fold icmp ugt/ult (add nuw X, C2), C --> icmp ugt/ult X, (C - C2)Nicola Zaghen2018-09-041-1/+1
| | | | | | | | | | Support for sgt/slt was added in rL294898, this adds the same cases also for unsigned compares. This is the Alive proof: https://rise4fun.com/Alive/nyY Differential Revision: https://reviews.llvm.org/D50972 llvm-svn: 341353
* Fix llvm::ComputeNumSignBits with some operations and llvm.assumeStanislav Mekhanoshin2018-07-251-0/+109
| | | | | | | | | | Currently ComputeNumSignBits does early exit while processing some of the operations (add, sub, mul, and select). This prevents the function from using AssumptionCacheTracker if passed. Differential Revision: https://reviews.llvm.org/D49759 llvm-svn: 337936
* Simplify recursive launder.invariant.group and stripPiotr Padlewski2018-07-121-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is crucial for proving equality laundered/stripped pointers. eg: bool foo(A *a) { return a == std::launder(a); } Clang with -fstrict-vtable-pointers will emit something like: define dso_local zeroext i1 @_Z3fooP1A(%struct.A* %a) { entry: %c = bitcast %struct.A* %a to i8* %call = tail call i8* @llvm.launder.invariant.group.p0i8(i8* %c) %0 = bitcast %struct.A* %a to i8* %1 = tail call i8* @llvm.strip.invariant.group.p0i8(i8* %0) %2 = tail call i8* @llvm.strip.invariant.group.p0i8(i8* %call) %cmp = icmp eq i8* %1, %2 ret i1 %cmp } and because %2 can be replaced with @llvm.strip.invariant.group(%0) and that %2 and %1 will produce the same value (because strip is readnone) we can replace compare with true. Reviewers: rsmith, hfinkel, majnemer, amharc, kuhar Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D47423 llvm-svn: 336963
* Revert "[InstCombine] Delay foldICmpUsingKnownBits until simple transforms ↵Max Kazantsev2018-07-061-1/+1
| | | | | | are done" llvm-svn: 336410
* [InstCombine] Delay foldICmpUsingKnownBits until simple transforms are doneMax Kazantsev2018-07-031-1/+1
| | | | | | | | | | | | This patch changes order of transform in InstCombineCompares to avoid performing transforms based on ranges which produce complex bit arithmetics before more simple things (like folding with constants) are done. See PR37636 for the motivating example. Differential Revision: https://reviews.llvm.org/D48584 Reviewed By: spatel, lebedev.ri llvm-svn: 336172
* Implement strip.invariant.groupPiotr Padlewski2018-07-021-2/+19
| | | | | | | | | | | | | | | | Summary: This patch introduce new intrinsic - strip.invariant.group that was described in the RFC: Devirtualization v2 Reviewers: rsmith, hfinkel, nlopes, sanjoy, amharc, kuhar Subscribers: arsenm, nhaehnle, JDevlieghere, hiraditya, xbolva00, llvm-commits Differential Revision: https://reviews.llvm.org/D47103 Co-authored-by: Krzysztof Pszeniczny <krzysztof.pszeniczny@gmail.com> llvm-svn: 336073
* Fix aliasing of launder.invariant.groupPiotr Padlewski2018-05-231-0/+21
| | | | | | | | | | | | | | | | | | | Summary: Patch for capture tracking broke bootstrap of clang with -fstict-vtable-pointers which resulted in debbugging nightmare. It was fixed https://reviews.llvm.org/D46900 but as it turned out, there were other parts like inliner (computing of noalias metadata) that I found after bootstraping with enabled assertions. Reviewers: hfinkel, rsmith, chandlerc, amharc, kuhar Subscribers: JDevlieghere, eraman, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D47088 llvm-svn: 333070
* Propagate nonnull and dereferenceable throught launderPiotr Padlewski2018-05-182-0/+44
| | | | | | | | | | | | | | | Summary: invariant.group.launder should not stop propagation of nonnull and dereferenceable, because e.g. we would not be able to hoist loads speculatively. Reviewers: rsmith, amharc, kuhar, xbolva00, hfinkel Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D46972 llvm-svn: 332788
* [IR] Do not assume that function pointers are alignedMikhail Maltsev2018-04-271-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The value tracking analysis uses function alignment to infer that the least significant bits of function pointers are known to be zero. Unfortunately, this is not correct for ARM targets: the least significant bit of a function pointer stores the ARM/Thumb state information (i.e., the LSB is set for Thumb functions and cleared for ARM functions). The original approach (https://reviews.llvm.org/D44781) introduced a new field for function pointer alignment in the DataLayout structure to address this. But it seems unlikely that optimizations based on function pointer alignment would bring much benefit in practice to justify the additional maintenance burden, so this patch simply assumes that function pointer alignment is always unknown. Reviewers: javed.absar, efriedma Reviewed By: efriedma Subscribers: kristof.beyls, llvm-commits, hfinkel, rogfer01 Differential Revision: https://reviews.llvm.org/D46110 llvm-svn: 331025
* [ValueTracking] add recursion depth param to matchSelectPattern Sanjay Patel2018-01-241-0/+46
| | | | | | | | | | | | | | | | | | | | | | | We're getting bug reports: https://bugs.llvm.org/show_bug.cgi?id=35807 https://bugs.llvm.org/show_bug.cgi?id=35840 https://bugs.llvm.org/show_bug.cgi?id=36045 ...where we blow up the stack in value tracking because other passes are sending in selects that have an operand that is itself the select. We don't currently have a reliable way to avoid analyzing dead code that may take non-standard forms, so bail out when things go too far. This mimics the recursion depth limitations in other parts of value tracking. Unfortunately, this pushes the underlying problems for other passes (jump-threading, simplifycfg, correlated-propagation) into hiding. If someone wants to uncover those again, the first draft of this patch on Phab would do that (it would assert rather than bail out). Differential Revision: https://reviews.llvm.org/D42442 llvm-svn: 323331
* [ValueTracking] Adding missed lit-test for commit r316208Nikolai Bozhenov2018-01-041-0/+27
| | | | | | | | | | Reviewers: reames, hfinkel Differential Revision: https://reviews.llvm.org/D34101 Patch by: Olga Chupina <olga.chupina@intel.com> llvm-svn: 321792
* Give up on array allocas in getPointerDereferenceableBytesBjorn Steinbrink2017-12-201-12/+0
| | | | | | | | | | | | | | | Summary: As suggested by Eli Friedman, don't try to handle array allocas here, because of possible overflows, instead rely on instcombine converting them to allocations of array types. Reviewers: efriedma Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41398 llvm-svn: 321159
* Treat sret arguments as being dereferenceable in ↵Bjorn Steinbrink2017-12-191-1/+11
| | | | | | | | | | | | getPointerDereferenceableBytes() Reviewers: rnk, hfinkel, efriedma Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41355 llvm-svn: 321061
* Re-commit "Properly handle multi-element and dynamically sized allocas in ↵Bjorn Steinbrink2017-12-171-0/+17
| | | | | | | | | getPointerDereferenceableBytes()"" llvm-clang-x86_64-expensive-checks-win is still broken, so the failure seems unrelated. llvm-svn: 320953
* Revert "Properly handle multi-element and dynamically sized allocas in ↵Bjorn Steinbrink2017-12-171-17/+0
| | | | | | | | | | getPointerDereferenceableBytes()" This reverts commit 217067d5179882de9deb60d2e866befea4c126e7. Fails on llvm-clang-x86_64-expensive-checks-win llvm-svn: 320945
* Properly handle byval arguments in getPointerDereferenceableBytes()Bjorn Steinbrink2017-12-171-1/+15
| | | | | | | | | | | | | | Summary: For byval arguments, the number of dereferenceable bytes is equal to the size of the pointee, not the pointer. Reviewers: hfinkel, rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41305 llvm-svn: 320939
* Properly handle multi-element and dynamically sized allocas in ↵Bjorn Steinbrink2017-12-171-0/+17
| | | | | | | | | | | | getPointerDereferenceableBytes() Reviewers: hfinkel, rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41288 llvm-svn: 320938
* [ValueTracking] return zero when there's conflict in known bits of a shift ↵Sanjay Patel2017-10-121-10/+4
| | | | | | | | (PR34838) Poison allows us to return a better result than undef. llvm-svn: 315595
* [ValueTracking] Don't delete assumes of side-effectful instructionsHal Finkel2017-08-141-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | ValueTracking has to strike a balance when attempting to propagate information backwards from assumes, because if the information is trivially propagated backwards, it can appear to LLVM that the assumption is known to be true, and therefore can be removed. This is sound (because an assumption has no semantic effect except for causing UB), but prevents the assume from allowing further optimizations. The isEphemeralValueOf check exists to try and prevent this issue by not removing the source of an assumption. This tries to make it a little bit more general to handle the case of side-effectful instructions, such as in %0 = call i1 @get_val() %1 = xor i1 %0, true call void @llvm.assume(i1 %1) Patch by Ariel Ben-Yehuda, thanks! Differential Revision: https://reviews.llvm.org/D36590 llvm-svn: 310859
* [ValueTracking] Revert r310583 which enabled functionality that still isChandler Carruth2017-08-141-27/+0
| | | | | | | | | | | | | | | | | | | | | | | | | causing compile time issues. Moreover, the patch *deleted* the flag in addition to changing the default, and links to a code review that doesn't even discuss the flag and just has an update to a Clang test case. I've followed up on the commit thread to ask for numbers on compile time at this point, leaving the flag in place until things stabilize, and pointing at specific code that seems to exhibit excessive compile time with this patch. Original commit message for r310583: """ [ValueTracking] Enabling ValueTracking patch by default (recommit). Part 2. The original patch was an improvement to IR ValueTracking on non-negative integers. It has been checked in to trunk (D18777, r284022). But was disabled by default due to performance regressions. Perf impact has improved. The patch would be enabled by default. """" llvm-svn: 310816
* [ValueTracking] Enabling ValueTracking patch by default (recommit). Part 2.Nikolai Bozhenov2017-08-101-0/+27
| | | | | | | | | | | | | | | The original patch was an improvement to IR ValueTracking on non-negative integers. It has been checked in to trunk (D18777, r284022). But was disabled by default due to performance regressions. Perf impact has improved. The patch would be enabled by default. Reviewers: reames, hfinkel Differential Revision: https://reviews.llvm.org/D34101 Patch by: Olga Chupina <olga.chupina@intel.com> llvm-svn: 310583
* [ValueTracking] use nonnull argument attribute to eliminate null checksSanjay Patel2017-02-121-7/+50
| | | | | | | | | | | Enhancing value tracking's analysis of null-ness was suggested in D27855, so here's a first attempt at that. This is part of solving: https://llvm.org/bugs/show_bug.cgi?id=28430 Differential Revision: https://reviews.llvm.org/D28204 llvm-svn: 294897
* [ValueTracking] regenerate checks; NFCSanjay Patel2017-01-091-7/+15
| | | | llvm-svn: 291468
* [ValueTracking] add tests for known-nonnull-at; NFCSanjay Patel2016-12-311-0/+57
| | | | llvm-svn: 290790
* [InstSimplify] allow integer vector types to use computeKnownBitsSanjay Patel2016-11-271-15/+3
| | | | | | | | Note that the non-splat lshr+lshr test folded, but that does not work in general. Something is missing or wrong in computeKnownBits as the non-splat shl+shl test still shows. llvm-svn: 288005
* add tests to show missing analysis; NFCSanjay Patel2016-11-271-0/+71
| | | | llvm-svn: 287998
* Fix known zero bits for addrspacecast.Yaxun Liu2016-11-211-0/+24
| | | | | | | | | | Currently LLVM assumes that a pointer addrspacecasted to a different addr space is equivalent to trunc or zext bitwise, which is not true. For example, in amdgcn target, when a null pointer is addrspacecasted from addr space 4 to 0, its value is changed from i64 0 to i32 -1. This patch teaches LLVM not to assume known bits of addrspacecast instruction to its operand. Differential Revision: https://reviews.llvm.org/D26803 llvm-svn: 287545
* [Loads] Fix crash in is isDereferenceableAndAlignedPointer()Tom Stellard2016-10-281-0/+21
| | | | | | | | | | | | | | | Summary: We were trying to add APInt values with different bit sizes after visiting an addrspacecast instruction which changed the bit width of the pointer. Reviewers: majnemer, hfinkel Subscribers: hfinkel, wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D24774 llvm-svn: 285407
* [ValueTracking] Fix crash in GetPointerBaseWithConstantOffset()Tom Stellard2016-10-071-0/+26
| | | | | | | | | | | | | | | | | | | Summary: While walking defs of pointer operands we were assuming that the pointer size would remain constant. This is not true, because addresspacecast instructions may cast the pointer to an address space with a different pointer width. This partial reverts r282612, which was a more conservative solution to this problem. Reviewers: reames, sanjoy, apilipenko Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D24772 llvm-svn: 283557
* [ValueTracking] Teach computeKnownBits and ComputeNumSignBits to look ↵Bjorn Pettersson2016-10-061-0/+28
| | | | | | | | | | | | | | | through ExtractElement. Summary: The computeKnownBits and ComputeNumSignBits functions in ValueTracking can now do a simple look-through of ExtractElement. Reviewers: majnemer, spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24955 llvm-svn: 283434
* auto-generate checksSanjay Patel2016-09-161-2/+4
| | | | llvm-svn: 281756
* The patch improves ValueTracking on left shift with nsw flag.Evgeny Stupachenko2016-08-241-0/+55
| | | | | | | | | | | | Summary: The patch fixes PR28946. Reviewers: majnemer, sanjoy Differential Revision: http://reviews.llvm.org/D23296 From: Li Huang llvm-svn: 279684
* Remove missing file from r279433 reversalArtur Pilipenko2016-08-221-97/+0
| | | | llvm-svn: 279434
* Revert "[ValueTracking] Improve ValueTracking on left shift with nsw flag"Sanjoy Das2016-08-151-24/+0
| | | | | | This reverts commit r278172. It causes PR28946. llvm-svn: 278740
* [ValueTracking] An improvement to IR ValueTracking on Non-negative IntegersAndrew Kaylor2016-08-101-0/+97
| | | | | | | | Patch by Li Huang Differential Revision: https://reviews.llvm.org/D18777 llvm-svn: 278267
* [ValueTracking] Improve ValueTracking on left shift with nsw flagAndrew Kaylor2016-08-091-0/+24
| | | | | | | | Patch by Li Huang Differential Revison: https://reviews.llvm.org/D23296 llvm-svn: 278172
* Teach isDereferenceablePointer to look through returned-argument functionsHal Finkel2016-07-111-1/+4
| | | | | | | | | For functions which are known to return their argument, isDereferenceableAndAlignedPointer can examine the argument value. Differential Revision: http://reviews.llvm.org/D9384 llvm-svn: 275038
* Reduce dependence on pointee types when deducing dereferenceabilitySanjoy Das2016-06-011-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Change some of the internal interfaces in Loads.cpp to keep track of the number of bytes we're trying to prove dereferenceable using an explicit `Size` parameter. Before this, the `Size` parameter was implicitly inferred from the pointee type of the pointer whose dereferenceability we were trying to prove, causing us to be conservative around bitcasts. This was unfortunate since bitcast instructions are no-ops and should never break optimizations. With an explicit `Size` parameter, we're more precise (as shown in the test cases), and the code is simpler. We should eventually move towards a `DerefQuery` struct that groups together a base pointer, an offset, a size and an alignment; but this patch is a first step. Reviewers: apilipenko, dblaikie, hfinkel, reames Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D20764 llvm-svn: 271406
* Use DL preferred alignment for alloca in Value::getPointerAlignmentArtur Pilipenko2016-04-271-1/+7
| | | | | | | | | | Teach Value::getPointerAlignment that allocas with no explicit alignment are aligned to preferred alignment of the allocated type. Reviewed By: hfinkel Differential Revision: http://reviews.llvm.org/D17569 llvm-svn: 267689
OpenPOWER on IntegriCloud