aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/ValueTracking.cpp
AgeCommit message (Collapse)AuthorFilesLines
2017-10-12[ScheduleDAGInstrs] fix behavior of getUnderlyingObjectsForCodeGen when no ↵Hiroshi Inoue1-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
2017-10-11[NFC] Convert OptimizationRemarkEmitter old emit() calls to new closureVivek Pandya1-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
2017-10-09Rename OptimizationDiagnosticInfo.* to OptimizationRemarkEmitter.*Adam Nemet1-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
2017-09-09Merge isKnownNonNull into isKnownNonZeroNuno Lopes1-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
2017-09-05[ValueTracking, InstCombine] canonicalize fcmp ord/uno with non-NAN ops to ↵Sanjay Patel1-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
2017-09-01[Analysis, Transforms] Fix some Clang-tidy modernize and Include What You ↵Eugene Zelenko1-20/+50
Use warnings; other minor fixes (NFC). llvm-svn: 312383
2017-08-21[ValueTracking] Add assertions that the starting Depth in ↵Craig Topper1-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
2017-08-18[InstCombine] Teach ComputeNumSignBitsImpl to handle integer multiply ↵Amjad Aboud1-0/+11
instruction. Differential Revision: https://reviews.llvm.org/D36679 llvm-svn: 311206
2017-08-14[ValueTracking] Don't delete assumes of side-effectful instructionsHal Finkel1-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
2017-08-14[ValueTracking] Revert r310583 which enabled functionality that still isChandler Carruth1-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
2017-08-10[ValueTracking] Enabling ValueTracking patch by default (recommit). Part 2.Nikolai Bozhenov1-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
2017-08-09[ValueTracking] Turn a test into an assertion.Davide Italiano1-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
2017-08-09[ValueTracking] Honour recursion limit.Davide Italiano1-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
2017-08-08[KnownBits][ValueTracking] Move the math for calculating known bits for ↵Craig Topper1-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
2017-08-04[InstCombine] Canonicalize clamp of float types to minmax in fast mode.Nikolai Bozhenov1-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
2017-08-02[StackColoring] Update AliasAnalysis information in stack coloring pass (part 2)Hiroshi Inoue1-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
2017-08-01[Value Tracking] Default argument to true and rename accordingly. NFC.Chad Rosier1-11/+11
IMHO this is a bit more readable. llvm-svn: 309739
2017-08-01[Value Tracking] Refactor and/or logic into helper. NFC.Chad Rosier1-40/+52
llvm-svn: 309726
2017-08-01[StackColoring] Update AliasAnalysis information in stack coloring passHiroshi Inoue1-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
2017-07-28[Value Tracking] Refactor icmp comparison logic into helper. NFC.Chad Rosier1-41/+62
llvm-svn: 309417
2017-07-28[ValueTracking] Remove a number of unused arguments. NFC.Chad Rosier1-26/+17
llvm-svn: 309385
2017-07-11Revert r307581, "Avoid doing conservative phi checks in ↵NAKAMURA Takumi1-1/+1
aliasSameBasePointerGEPs() if no phis have been visited yet." It broke stage2 tests in selfhosting. llvm-svn: 307613
2017-07-10Avoid doing conservative phi checks in aliasSameBasePointerGEPs() if no phis ↵Farhana Aleen1-1/+1
have been visited yet. Reviewers: Daniel Berlin Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34478 llvm-svn: 307581
2017-07-09[IR] Add Type::isIntOrIntVectorTy(unsigned) similar to the existing ↵Craig Topper1-5/+3
isIntegerTy(unsigned), but also works for vectors. llvm-svn: 307492
2017-07-09[IR] Make use of ↵Craig Topper1-1/+1
Type::isPtrOrPtrVectorTy/isIntOrIntVectorTy/isFPOrFPVectorTy to shorten code. NFC llvm-svn: 307491
2017-07-07[ValueTracking] Fix the identity case (LHS => RHS) when the LHS is false.Chad Rosier1-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
2017-07-06[ValueTracking] Support icmps fed by 'and' and 'or'.Chad Rosier1-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
2017-07-06[Constants] If we already have a ConstantInt*, prefer to use ↵Craig Topper1-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
2017-06-30Revert of r306525: "Canonicalize clamp of float types to minmax"Nikolai Bozhenov1-68/+1
llvm-svn: 306815
2017-06-28Revert r306528Nikolai Bozhenov1-0/+9
llvm-svn: 306536
2017-06-28[ValueTracking] Enabling existing ValueTracking patch by default.Nikolai Bozhenov1-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 Differential Revision: https://reviews.llvm.org/D34101 Patch by: Olga Chupina <olga.chupina@intel.com> llvm-svn: 306528
2017-06-28[InstCombine] Canonicalize clamp of float types to minmax in fast mode.Nikolai Bozhenov1-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: 306525
2017-06-24[ValueTracking][InstCombine] Use m_Shr instead m_CombineOr(m_LShr, m_AShr). NFCCraig Topper1-5/+2
llvm-svn: 306205
2017-06-14[ValueTracking] Correct early out in computeKnownBitsFromOperator to work ↵Craig Topper1-1/+2
with non power of 2 bit widths There's an early out that's trying to detect when we don't know any bits that make up the legal range of a shift. The code subtracts one from BitWidth which creates a mask in the lower bits for power of 2 bit widths. This is then ANDed with the known bits to see if any of those bits are known. If the bit width isn't a power of 2 this creates a non-sensical mask. This patch corrects this by rounding up to a power of 2 before doing the subtract and mask. Differential Revision: https://reviews.llvm.org/D34165 llvm-svn: 305400
2017-06-12fix typos/formatting; NFCSanjay Patel1-1/+1
llvm-svn: 305243
2017-06-09[ValueTracking] fix typo; NFCSanjay Patel1-1/+1
llvm-svn: 305080
2017-06-06Sort the remaining #include lines in include/... and lib/....Chandler Carruth1-1/+1
I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
2017-06-06[ValueTracking] Remove scalar only restriction from isKnownNonEqual. The ↵Craig Topper1-2/+2
computeKnownBits and isKnownNonZero calls this code relies on should work fine for vectors. This will be used by another commit to remove some code from InstSimplify that is redundant for scalars, but was needed for vectors due to this issue. llvm-svn: 304774
2017-06-06[ValueTracking] Use the computeKnownBits version that returns a KnownBits ↵Craig Topper1-6/+3
object instead of taking one by reference. NFC llvm-svn: 304772
2017-06-06[ValueTracking] Use APInt::intersects to avoid some temporary APInts. NFCCraig Topper1-3/+2
llvm-svn: 304771
2017-05-31Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova1-0/+1
llvm-svn: 304361
2017-05-31[PPC] Inline expansion of memcmpZaara Syeda1-0/+12
This patch does an inline expansion of memcmp. It changes the memcmp library call into an inline expansion when the size is known at compile time and is under a target specified threshold. This expansion is implemented in CodeGenPrepare and expands into straight line code. The target specifies a maximum load size and the expansion works by using this size to load the two sources, compare, and exit early if a difference is found. It also has a special case when the memcmp result is used in a compare to zero equality. Differential Revision: https://reviews.llvm.org/D28637 llvm-svn: 304313
2017-05-24[ValueTracking] Add OptimizationRemarkEmitter to the other signature for ↵Craig Topper1-2/+4
commuteKnownBits. This is needed for an upcoming patch. llvm-svn: 303772
2017-05-19SimplifyLibCalls: Optimize wcslenMatthias Braun1-34/+88
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
2017-05-15[ValueTracking] Replace all uses of ComputeSignBit with computeKnownBits.Craig Topper1-9/+0
This patch finishes off the conversion of ComputeSignBit to computeKnownBits. Differential Revision: https://reviews.llvm.org/D33166 llvm-svn: 303035
2017-05-15[InstCombine] Merge duplicate functionality between InstCombine and ↵Craig Topper1-5/+66
ValueTracking Summary: Merge overflow computation for signed add, appearing both in InstCombine and ValueTracking. As part of the merge, cleanup the interface for overflow checks in InstCombine. Patch by Yoav Ben-Shalom. Reviewers: craig.topper, majnemer Reviewed By: craig.topper Subscribers: takuto.ikuta, llvm-commits Differential Revision: https://reviews.llvm.org/D32946 llvm-svn: 303029
2017-05-12[KnownBits] Add bit counting methods to KnownBits struct and use them where ↵Craig Topper1-39/+31
possible This patch adds min/max population count, leading/trailing zero/one bit counting methods. The min methods return answers based on bits that are known without considering unknown bits. The max methods give answers taking into account the largest count that unknown bits could give. Differential Revision: https://reviews.llvm.org/D32931 llvm-svn: 302925
2017-05-08[ValueTracking] Use KnownOnes to provide a better bound on known zeros for ↵Craig Topper1-3/+16
ctlz/cttz intrinics This patch uses KnownOnes of the input of ctlz/cttz to bound the value that can be returned from these intrinsics. This makes these intrinsics more similar to the handling for ctpop which already uses known bits to produce a similar bound. Differential Revision: https://reviews.llvm.org/D32521 llvm-svn: 302444
2017-05-08[ValueTracking] Introduce a version of computeKnownBits that returns a ↵Craig Topper1-67/+52
KnownBits struct. Begin using it to replace internal usages of ComputeSignBit This introduces a new interface for computeKnownBits that returns the KnownBits object instead of requiring it to be pre-constructed and passed in by reference. This is a much more convenient interface as it doesn't require the caller to figure out the BitWidth to pre-construct the object. It's so convenient that I believe we can use this interface to remove the special ComputeSignBit flavor of computeKnownBits. As a step towards that idea, this patch replaces all of the internal usages of ComputeSignBit with this new interface. As you can see from the patch there were a couple places where we called ComputeSignBit which really called computeKnownBits, and then called computeKnownBits again directly. I've reduced those places to only making one call to computeKnownBits. I bet there are probably external users that do it too. A future patch will update the external users and remove the ComputeSignBit interface. I'll also working on moving more locations to the KnownBits returning interface for computeKnownBits. Differential Revision: https://reviews.llvm.org/D32848 llvm-svn: 302437
2017-05-05[KnownBits] Add wrapper methods for setting and clear all bits in the ↵Craig Topper1-32/+18
underlying APInts in KnownBits. This adds routines for reseting KnownBits to unknown, making the value all zeros or all ones. It also adds methods for querying if the value is zero, all ones or unknown. Differential Revision: https://reviews.llvm.org/D32637 llvm-svn: 302262
generated by cgit v1.1 at 2025-10-17 02:24:10 +0000