summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/ValueTracking.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [InlineCost] Find repeated loads in the calleeHaicheng Wu2017-12-151-1/+1
| | | | | | | | | | | SROA analysis of InlineCost can figure out that some stores can be removed after inlining and then the repeated loads clobbered by these stores are also free. This patch finds these clobbered loads and adjust the inline cost accordingly. Differential Revision: https://reviews.llvm.org/D33946 llvm-svn: 320814
* Infer lowest bits of an integer Multiply when the low bits of the operands ↵Simon Dardis2017-12-091-9/+66
| | | | | | | | | | | | | | | are known When the lowest bits of the operands to an integer multiply are known, the low bits of the result are deducible. Code to deduce known-zero bottom bits already existed, but this change improves on that by deducing known-ones. Patch by: Pedro Ferreira Reviewers: craig.topper, sanjoy, efriedma Differential Revision: https://reviews.llvm.org/D34029 llvm-svn: 320269
* Hardware-assisted AddressSanitizer (llvm part).Evgeniy Stepanov2017-12-091-1/+2
| | | | | | | | | | | | | | | | | | | | | Summary: This is LLVM instrumentation for the new HWASan tool. It is basically a stripped down copy of ASan at this point, w/o stack or global support. Instrumenation adds a global constructor + runtime callbacks for every load and store. HWASan comes with its own IR attribute. A brief design document can be found in clang/docs/HardwareAssistedAddressSanitizerDesign.rst (submitted earlier). Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, mehdi_amini, mgorny, javed.absar, eraman, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D40932 llvm-svn: 320217
* [InstCombine] Don't crash on out of bounds shiftsIgor Laevsky2017-12-051-13/+17
| | | | | | Differential Revision: https://reviews.llvm.org/D40649 llvm-svn: 319761
* Revert "[ValueTracking] Pass only a single lambda to ↵Sam McCall2017-12-041-29/+37
| | | | | | | | | computeKnownBitsFromShiftOperator by using KnownBits struct instead of separate APInts. NFCI" This reverts commit r319624, which seems to cause a miscompile (breaks the multistage PPC buildbots) llvm-svn: 319652
* [ValueTracking] Pass only a single lambda to ↵Craig Topper2017-12-021-37/+29
| | | | | | computeKnownBitsFromShiftOperator by using KnownBits struct instead of separate APInts. NFCI llvm-svn: 319624
* [ValueTracking] use 'auto' with 'dyn_cast'; NFCSanjay Patel2017-11-131-11/+13
| | | | llvm-svn: 318058
* [ValueTracking] simplify code in CannotBeNegativeZero() with match(); NFCISanjay Patel2017-11-131-5/+3
| | | | llvm-svn: 318055
* Add an @llvm.sideeffect intrinsicDan Gohman2017-11-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements Chandler's idea [0] for supporting languages that require support for infinite loops with side effects, such as Rust, providing part of a solution to bug 965 [1]. Specifically, it adds an `llvm.sideeffect()` intrinsic, which has no actual effect, but which appears to optimization passes to have obscure side effects, such that they don't optimize away loops containing it. It also teaches several optimization passes to ignore this intrinsic, so that it doesn't significantly impact optimization in most cases. As discussed on llvm-dev [2], this patch is the first of two major parts. The second part, to change LLVM's semantics to have defined behavior on infinite loops by default, with a function attribute for opting into potential-undefined-behavior, will be implemented and posted for review in a separate patch. [0] http://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html [1] https://bugs.llvm.org/show_bug.cgi?id=965 [2] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118632.html Differential Revision: https://reviews.llvm.org/D38336 llvm-svn: 317729
* [ValueTracking] Use APInt::isNullValue/isOneValue which are more efficient ↵Craig Topper2017-11-081-3/+6
| | | | | | for large APInts. llvm-svn: 317712
* [ValueTracking] readonly (const) is a requirement for converting sqrt to ↵Sanjay Patel2017-11-061-3/+1
| | | | | | | | | | | | | | | | | | | | | | llvm.sqrt; nnan is not As discussed in D39204, this is effectively a revert of rL265521 which required nnan to vectorize sqrt libcalls based on the old LangRef definition of llvm.sqrt. Now that the definition has been updated so the libcall and intrinsic have the same semantics apart from potentially setting errno, we can remove the nnan requirement. We have the right check to know that errno is not set: if (!ICS.onlyReadsMemory()) ...ahead of the switch. This will solve https://bugs.llvm.org/show_bug.cgi?id=27435 assuming that's being built for a target with -fno-math-errno. Differential Revision: https://reviews.llvm.org/D39642 llvm-svn: 317519
* Improve clamp recognition in ValueTracking.Artur Gainullin2017-10-271-12/+26
| | | | | | | | | | | | | | | | Summary: ValueTracking was recognizing not all variations of clamp. Swapping of true value and false value of select was added to fix this problem. The first patch was reverted because it caused miscompile in NVPTX target. Added corresponding test cases. Reviewers: spatel, majnemer, efriedma, reames Subscribers: llvm-commits, jholewinski Differential Revision: https://reviews.llvm.org/D39240 llvm-svn: 316795
* [ValueTracking] Remove unnecessary temporary APInt from ↵Craig Topper2017-10-211-5/+1
| | | | | | | | computeNumSignBitsVectorConstant. We can just use getNumSignBits instead of inverting negative numbers. llvm-svn: 316266
* [ValueTracking] Simplify the known bits code for constant vectors a little.Craig Topper2017-10-211-4/+2
| | | | | | Neither of these cases really require a temporary APInt outside the loop. For the ConstantDataSequential case the APInt will never be larger than 64-bits so its fine to just call getElementAsAPInt. For ConstantVector we can get the APInt by reference and only make a copy where the inversion is needed. llvm-svn: 316265
* [ValueTracking] Enabling ValueTracking patch by default Nikolai Bozhenov2017-10-201-9/+0
| | | | | | | | | | | | | | | | | (recommit #2 after checking for timeout issue). 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: 316208
* Revert r315992 because of a found miscompilation failureNikolai Bozhenov2017-10-191-33/+12
| | | | llvm-svn: 316164
* Fixup patch for revision rL316070.Nikolai Bozhenov2017-10-181-1/+2
| | | | | | | | | | | | | | Added check that type of CmpConst and source type of trunc are equal for correct matching of the case when we can set widened C constant equal to CmpConstant. %cond = cmp iN %x, CmpConst %tr = trunc iN %x to iK %narrowsel = select i1 %cond, iK %t, iK C Patch by: Gainullin, Artur <artur.gainullin@intel.com> llvm-svn: 316082
* Improve lookThroughCast function.Nikolai Bozhenov2017-10-181-1/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we have the following case: %cond = cmp iN %x, CmpConst %tr = trunc iN %x to iK %narrowsel = select i1 %cond, iK %t, iK C We could possibly match only min/max pattern after looking through cast. So it is more profitable if widened C constant will be equal CmpConst. That is why just set widened C constant equal to CmpConst, because there is a further check in this function that trunc CmpConst == C. Also description for lookTroughCast function was added. Reviewers: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38536 Patch by: Artur Gainullin <artur.gainullin@intel.com> llvm-svn: 316070
* Improve clamp recognition in ValueTracking.Nikolai Bozhenov2017-10-171-12/+33
| | | | | | | | | | | | | | | | | | | Summary: ValueTracking was recognizing not all variations of clamp. Swapping of true value and false value of select was added to fix this problem. This change breaks the canonical form of cmp inside the matchMinMax function, that is why additional checks for compare predicates is needed. Added corresponding test cases. Reviewers: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38531 Patch by: Artur Gainullin <artur.gainullin@intel.com> llvm-svn: 315992
* [ValueTracking] fix typos, formatting; NFCSanjay Patel2017-10-161-11/+10
| | | | llvm-svn: 315909
* [ValueTracking] return zero when there's conflict in known bits of a shift ↵Sanjay Patel2017-10-121-14/+12
| | | | | | | | (PR34838) Poison allows us to return a better result than undef. llvm-svn: 315595
* [ScheduleDAGInstrs] fix behavior of getUnderlyingObjectsForCodeGen when no ↵Hiroshi Inoue2017-10-121-2/+4
| | | | | | | | | | | | | | | identifiable object found This patch fixes the bug introduced in https://reviews.llvm.org/D35907; the bug is reported by http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20171002/491452.html. Before D35907, when GetUnderlyingObjects fails to find an identifiable object, allMMOsOkay lambda in getUnderlyingObjectsForInstr returns false and Objects vector is cleared. This behavior is unintentionally changed by D35907. This patch makes the behavior for such case same as the previous behavior. Since D35907 introduced a wrapper function getUnderlyingObjectsForCodeGen around GetUnderlyingObjects, getUnderlyingObjectsForCodeGen is modified to return a boolean value to ask the caller to clear the Objects vector. Differential Revision: https://reviews.llvm.org/D38735 llvm-svn: 315565
* [NFC] Convert OptimizationRemarkEmitter old emit() calls to new closureVivek Pandya2017-10-111-7/+9
| | | | | | | | | | | | | | parameterized emit() calls Summary: This is not functional change to adopt new emit() API added in r313691. Reviewed By: anemet Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38285 llvm-svn: 315476
* Rename OptimizationDiagnosticInfo.* to OptimizationRemarkEmitter.*Adam Nemet2017-10-091-1/+1
| | | | | | | Sync it up with the name of the class actually defined here. This has been bothering me for a while... llvm-svn: 315249
* Merge isKnownNonNull into isKnownNonZeroNuno Lopes2017-09-091-97/+85
| | | | | | | | | It now knows the tricks of both functions. Also, fix a bug that considered allocas of non-zero address space to be always non null Differential Revision: https://reviews.llvm.org/D37628 llvm-svn: 312869
* [ValueTracking, InstCombine] canonicalize fcmp ord/uno with non-NAN ops to ↵Sanjay Patel2017-09-051-0/+35
| | | | | | | | | | | | | | | | | | | | | null constants This is a preliminary step towards solving the remaining part of PR27145 - IR for isfinite(): https://bugs.llvm.org/show_bug.cgi?id=27145 In order to solve that one more generally, we need to add matching for and/or of fcmp ord/uno with a constant operand. But while looking at those patterns, I realized we were missing a canonicalization for nonzero constants. Rather than limiting to just folds for constants, we're adding a general value tracking method for this based on an existing DAG helper. By transforming everything to 0.0, we can simplify the existing code in foldLogicOfFCmps() and pick up missing vector folds. Differential Revision: https://reviews.llvm.org/D37427 llvm-svn: 312591
* [Analysis, Transforms] Fix some Clang-tidy modernize and Include What You ↵Eugene Zelenko2017-09-011-20/+50
| | | | | | Use warnings; other minor fixes (NFC). llvm-svn: 312383
* [ValueTracking] Add assertions that the starting Depth in ↵Craig Topper2017-08-211-0/+3
| | | | | | | | isKnownToBeAPowerOfTwo and ComputeNumSignBitsImpl is not above MaxDepth The function does an equality check later to terminate the recursion, but that won't work if its starts out too high. Similar assert already exists in computeKnownBits. llvm-svn: 311400
* [InstCombine] Teach ComputeNumSignBitsImpl to handle integer multiply ↵Amjad Aboud2017-08-181-0/+11
| | | | | | | | instruction. Differential Revision: https://reviews.llvm.org/D36679 llvm-svn: 311206
* [ValueTracking] Don't delete assumes of side-effectful instructionsHal Finkel2017-08-141-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | 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-9/+0
| | | | | | | | | | | | | | | 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] Turn a test into an assertion.Davide Italiano2017-08-091-3/+1
| | | | | | | As discussed with Chad, this should never happen, but this assertion is basically free, so, keep it around just in case. llvm-svn: 310493
* [ValueTracking] Honour recursion limit.Davide Italiano2017-08-091-0/+4
| | | | | | | | | | | The recently improved support for `icmp` in ValueTracking (r307304) exposes the fact that `isImplied` condition doesn't really bail out if we hit the recursion limit (and calls `computeKnownBits` which increases the depth and asserts). Differential Revision: https://reviews.llvm.org/D36512 llvm-svn: 310481
* [KnownBits][ValueTracking] Move the math for calculating known bits for ↵Craig Topper2017-08-081-41/+1
| | | | | | | | | | | | add/sub into a static method in KnownBits object I want to reuse this code in SimplifyDemandedBits handling of Add/Sub. This will make that easier. Wonder if we should use it in SelectionDAG's computeKnownBits too. Differential Revision: https://reviews.llvm.org/D36433 llvm-svn: 310378
* [InstCombine] Canonicalize clamp of float types to minmax in fast mode.Nikolai Bozhenov2017-08-041-1/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit allows matchSelectPattern to recognize clamp of float arguments in the presence of FMF the same way as already done for integers. This case is a little different though. With integers, given the min/max pattern is recognized, DAGBuilder starts selecting MIN/MAX "automatically". That is not the case for float, because for them only full FMINNAN/FMINNUM/FMAXNAN/FMAXNUM ISD nodes exist and they do care about NaNs. On the other hand, some backends (e.g. X86) have only FMIN/FMAX nodes that do not care about NaNS and the former NAN/NUM nodes are illegal thus selection is not happening. So I decided to do such kind of transformation in IR (InstCombiner) instead of complicating the logic in the backend. Reviewers: spatel, jmolloy, majnemer, efriedma, craig.topper Reviewed By: efriedma Subscribers: hiraditya, javed.absar, n.bozhenov, llvm-commits Patch by Andrei Elovikov <andrei.elovikov@intel.com> Differential Revision: https://reviews.llvm.org/D33186 llvm-svn: 310054
* [StackColoring] Update AliasAnalysis information in stack coloring pass (part 2)Hiroshi Inoue2017-08-021-7/+6
| | | | | | | | | | | | | | | | | | | | | This patch is update after the first patch (https://reviews.llvm.org/rL309651) based on the post-commit comments. Stack coloring pass need to maintain AliasAnalysis information when merging stack slots of different types. Actually, there is a FIXME comment in StackColoring.cpp // FIXME: In order to enable the use of TBAA when using AA in CodeGen, // we'll also need to update the TBAA nodes in MMOs with values // derived from the merged allocas. But, TBAA has been already enabled in CodeGen without fixing this pass. The incorrect TBAA metadata results in recent failures in bootstrap test on ppc64le (PR33928) by allowing unsafe instruction scheduling. Although we observed the problem on ppc64le, this is a platform neutral issue. This patch makes the stack coloring pass maintains AliasAnalysis information when merging multiple stack slots. This patch fixes PR33928. llvm-svn: 309849
* [Value Tracking] Default argument to true and rename accordingly. NFC.Chad Rosier2017-08-011-11/+11
| | | | | | IMHO this is a bit more readable. llvm-svn: 309739
* [Value Tracking] Refactor and/or logic into helper. NFC.Chad Rosier2017-08-011-40/+52
| | | | llvm-svn: 309726
* [StackColoring] Update AliasAnalysis information in stack coloring passHiroshi Inoue2017-08-011-0/+64
| | | | | | | | | | | | | | | | | Stack coloring pass need to maintain AliasAnalysis information when merging stack slots of different types. Actually, there is a FIXME comment in StackColoring.cpp // FIXME: In order to enable the use of TBAA when using AA in CodeGen, // we'll also need to update the TBAA nodes in MMOs with values // derived from the merged allocas. But, TBAA has been already enabled in CodeGen without fixing this pass. The incorrect TBAA metadata results in recent failures in bootstrap test on ppc64le (PR33928) by allowing unsafe instruction scheduling. Although we observed the problem on ppc64le, this is a platform neutral issue. This patch makes the stack coloring pass maintains AliasAnalysis information when merging multiple stack slots. llvm-svn: 309651
* [Value Tracking] Refactor icmp comparison logic into helper. NFC.Chad Rosier2017-07-281-41/+62
| | | | llvm-svn: 309417
* [ValueTracking] Remove a number of unused arguments. NFC.Chad Rosier2017-07-281-26/+17
| | | | llvm-svn: 309385
* Revert r307581, "Avoid doing conservative phi checks in ↵NAKAMURA Takumi2017-07-111-1/+1
| | | | | | | | aliasSameBasePointerGEPs() if no phis have been visited yet." It broke stage2 tests in selfhosting. llvm-svn: 307613
* Avoid doing conservative phi checks in aliasSameBasePointerGEPs() if no phis ↵Farhana Aleen2017-07-101-1/+1
| | | | | | | | | | | | have been visited yet. Reviewers: Daniel Berlin Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34478 llvm-svn: 307581
* [IR] Add Type::isIntOrIntVectorTy(unsigned) similar to the existing ↵Craig Topper2017-07-091-5/+3
| | | | | | isIntegerTy(unsigned), but also works for vectors. llvm-svn: 307492
* [IR] Make use of ↵Craig Topper2017-07-091-1/+1
| | | | | | Type::isPtrOrPtrVectorTy/isIntOrIntVectorTy/isFPOrFPVectorTy to shorten code. NFC llvm-svn: 307491
* [ValueTracking] Fix the identity case (LHS => RHS) when the LHS is false.Chad Rosier2017-07-071-2/+2
| | | | | | | | | Prior to this commit both of the added test cases were passing. However, in the latter case (test7) we were doing a lot more work to arrive at the same answer (i.e., we were using isImpliedCondMatchingOperands() to determine the implication.). llvm-svn: 307400
* [ValueTracking] Support icmps fed by 'and' and 'or'.Chad Rosier2017-07-061-7/+32
| | | | | | | | | | This patch adds support for handling some forms of ands and ors in ValueTracking's isImpliedCondition API. PR33611 https://reviews.llvm.org/D34901 llvm-svn: 307304
* [Constants] If we already have a ConstantInt*, prefer to use ↵Craig Topper2017-07-061-1/+1
| | | | | | | | isZero/isOne/isMinusOne instead of isNullValue/isOneValue/isAllOnesValue inherited from Constant. NFCI Going through the Constant methods requires redetermining that the Constant is a ConstantInt and then calling isZero/isOne/isMinusOne. llvm-svn: 307292
* Revert of r306525: "Canonicalize clamp of float types to minmax"Nikolai Bozhenov2017-06-301-68/+1
| | | | llvm-svn: 306815
OpenPOWER on IntegriCloud