| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The code only works on integer casts, and the only bitcasts
involving integers are trivial. The code as previously written
would try to handle things like float to integer bitcasts by
fetching a ConstantRange of a float value, which is an ill-defined
operation.
|
|
The current implementation using a worklist and visited map adds
a significant amount of additional complexity and compile-time
overhead. All we really care about here is that we don't overflow
the stack or cause exponential complexity in degenerate cases. We
can achieve this with a simple depth limit.
|
|
We have a bunch of places where we have to guard against undef
to avoid multi-use issues, but would be fine with poison. Use a
different function for these to make it clear, and to indicate that
this check can be removed once we no longer support undef. I've
replaced some of the obvious cases, but there's probably more.
For now, the implementation is the same as UndefOrPoison, it just
has a more precise name.
|
|
This pass isn't used anywhere upstream and thus has no test coverage.
For these reasons, remove it.
|
|
This patch adds a NewPM printer pass for the LazyValueAnalysis.
|
|
This handles the case where this combine:
icmp sgt (ashr X, ShAmtC), C --> icmp sgt X, ((C + 1) << ShAmtC) - 1
wasn't performed by instcombine.
Proof of the original combine: https://alive2.llvm.org/ce/z/SfpsvX
This is a port of the review in https://reviews.llvm.org/D151911 to
GitHub.
|
|
When converting to ConstantRange, we should treat undef like a full range.
Fixes #68381.
|
|
gcc warned with:
[236/4788] Building CXX object lib/Analysis/CMakeFiles/LLVMAnalysis.dir/LazyValueInfo.cpp.o
../lib/Analysis/LazyValueInfo.cpp: In member function 'void llvm::LazyValueInfo::forgetValue(llvm::Value*)':
../lib/Analysis/LazyValueInfo.cpp:1978:13: warning: unused variable 'Impl' [-Wunused-variable]
1978 | if (auto *Impl = getImpl())
| ^~~~
../lib/Analysis/LazyValueInfo.cpp: In member function 'void llvm::LazyValueInfo::eraseBlock(llvm::BasicBlock*)':
../lib/Analysis/LazyValueInfo.cpp:1983:13: warning: unused variable 'Impl' [-Wunused-variable]
1983 | if (auto *Impl = getImpl())
| ^~~~
../lib/Analysis/LazyValueInfo.cpp: In member function 'void llvm::LazyValueInfo::clear()':
../lib/Analysis/LazyValueInfo.cpp:1988:13: warning: unused variable 'Impl' [-Wunused-variable]
1988 | if (auto *Impl = getImpl())
| ^~~~
../lib/Analysis/LazyValueInfo.cpp: In member function 'void llvm::LazyValueInfo::printLVI(llvm::Function&, llvm::DominatorTree&, llvm::raw_ostream&)':
../lib/Analysis/LazyValueInfo.cpp:1993:13: warning: unused variable 'Impl' [-Wunused-variable]
1993 | if (auto *Impl = getImpl())
| ^~~~
Use the locals instead of calling getImpl() again.
|
|
|
|
|
|
I don't believe this can happen right now (because we're only
working on icmps and as such can't hit the current fcmp null
paths), but this will be possible in the future when icmp
constant expressions are removed.
|
|
SelectInst
Fixes:https://github.com/llvm/llvm-project/issues/62901
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D151295
|
|
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
well-defined
If the condition value of SelectInst may be a poison or undef value,
infer constant range at SelectInst use is in correct.
See https://alive2.llvm.org/ce/z/MWMTYn
Fixes: https://github.com/llvm/llvm-project/issues/62200
Differential Revision: https://reviews.llvm.org/D148709
|
|
|
|
This fixes the handling of phi nodes in getConstantRangeAtUse()
and re-enables it, reverting the workaround from
c77c186a647b385c291ddabecd70a2b4f84ae342.
For phi nodes, while we can make use of the edge condition for the
incoming value, we shouldn't look past the phi node to look for
further conditions, because we might be reasoning about values
from two different cycle iterations (which will have the same
SSA value).
To handle this more specifically we would have to detect cycles,
and there doesn't seem to be any motivating case for that at this
point.
|
|
This effectively reverts 5c38c6a and 4f772b0.
A recently introduced LazyValueInfo::getConstantRangeAtUse returns incorrect
ranges for values in certain cases. One such example is described in PR60629.
The issue has something to do with traversing PHI uses of a value transitively.
As nikic pointed out, we're effectively reasoning about values from different
loop iterations.
In the faulting test case, CVP made a miscompilation because the calculated
range for a shift argument was incorrect. It returned empty-set, however it is
clearly not a dead code. CVP then erased the shift instruction because
of empty range.
|
|
Even if the intrinsic is supported by ConstantRange, we should
still make use of !range metadata. This doesn't matter much now,
but is important if we want to support ctlz style intrinsics,
which always have KnownBits-based !range metadata attached, which
might be better than what we can compute using ranges.
|
|
When constraining an operand based on a condition at a (potentially
transitive) use site, make sure we don't skip over non-speculatable
instructions. While the result is only used under the condition,
the non-speculatable instruction may have a side-effect or UB.
Demonstrating this issue requires raising the limit on the walk,
so do that.
|
|
When an instruction is only used in a select or phi operand, we might
be able to make use of additional information from the select/branch
condition. For example in
%sub = call i16 @llvm.usub.sat.i16(i16 %x, i16 10)
%cmp = icmp uge i16 %x, 10
%sel = select i1 %cmp, i16 %sub, i16 42
the usub.sat is only used in a select where %x uge 10 is known to
hold, so we can fold it based on that knowledge.
This addresses the regression reported at
https://reviews.llvm.org/D140798#4039748, but also provides a
solution to a recurring problem we've had, where we fail to make
use of range information after a branch+phi has been converted
into a select. Our current solution to this is to hope that IPSCCP
can perform the fold before that happens, but handling this in LVI
is a somewhat more general solution.
Currently we only make use of this for the willNotOverflow() fold,
but I plan to adjust other folds to use the new API as well.
Differential Revision: https://reviews.llvm.org/D141482
|
|
This teaches LVI (and thus CVP) to extract range information
from branches whose condition is negated using (`xor %c, true`).
On the implementation side, we switch the cache to additionally
track whether we're looking for the inverted value or not and
otherwise using the existing support for computing inverted
conditions.
I think the biggest question here is why this negation shows up
here at all. After all, it should always be possible for some
other pass to fold such a negation into a branch, comparison or
some other logical operation. Indeed, instcombine does just that.
However, these negations can be otherwise fairly persistent, e.g.
instsimplify is not able to exchange branch conditions from
negations. In addition, jumpthreading, which sits at the same
point in default pass pipeline also handles this pattern, which
adds further evidence that we might expect these negations to
not have been canonicalized away yet at this point in the pass
pipeline.
In the particular case I was looking at there was a bit of a
circular dependency where flags computed by cvp were needed
by instcombine, and incstombine's folding of the negation was
needed for cvp. Adding a second instombine pass would have
worked of course, but instcombine can be somewhat expensive,
so it appeared desirable to not require it to have run
before cvp (as is the case in the default pass pipeline).
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D140933
|
|
value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).
This commit fixes LLVMAnalysis and its dependencies.
|
|
These files no longer use llvm::Optional.
|
|
|
|
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
|
|
CVP currently only tries to simplify comparisons if there is a
constant operand. However, even if both are non-constant, we may
be able to determine the result of the comparison based on range
information.
IPSCCP is already capable of doing this, but because it runs very
early, it may miss some cases.
Differential Revision: https://reviews.llvm.org/D137253
|
|
|
|
|
|
This patch replaces Optional::hasValue with the implicit cast to bool
in conditionals only.
|
|
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
|
|
|
|
|
|
|
|
|
|
Clang-format InstructionSimplify and convert all "FunctionName"s to
"functionName". This patch does touch a lot of files but gets done with
the cleanup of InstructionSimplify in one commit.
This is the alternative to the less invasive clang-format only patch: D126783
Reviewed By: spatel, rengolin
Differential Revision: https://reviews.llvm.org/D126889
|
|
Most clients only used these methods because they wanted to be able to
extend or truncate to the same bit width (which is a no-op). Now that
the standard zext, sext and trunc allow this, there is no reason to use
the OrSelf versions.
The OrSelf versions additionally have the strange behaviour of allowing
extending to a *smaller* width, or truncating to a *larger* width, which
are also treated as no-ops. A small amount of client code relied on this
(ConstantRange::castOp and MicrosoftCXXNameMangler::mangleNumber) and
needed rewriting.
Differential Revision: https://reviews.llvm.org/D125557
|
|
We do have a non-trivial implementation for binaryXor() now.
|
|
This method just calls LazyValueInfoImpl::clear
|
|
Number of lines output by preprocessor:
before: 1065940348
after: 1065307662
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D120659
|
|
Similar to the existing urem code, if we have (trunc X) >= C,
then also X >= C.
Proof: https://alive2.llvm.org/ce/z/RF4YR2
Fixes https://github.com/llvm/llvm-project/issues/51867.
|
|
We need to check that the operands of the min/max are the operands
of the select, but we don't care which order they are in.
|
|
If we have a constant range for one operand but not the other,
we can generally still compute a useful results for SPF min/max.
|
|
Integrate intersection with assumes into getBlockValue(), to ensure
that it is consistently performed.
We were doing it in nearly all places, but for example missed it
for select inputs.
|
|
If we're looking only at the lower bound, the actual modulus
doesn't matter. This is a leftover from when I wanted to consider
the upper bound as well, where the modulus does matter.
|
|
If (X urem M) >= C we know that X >= C. Make use of this fact
when computing the implied condition range.
In some cases we could also establish an upper bound, but that's
both tricker and not interesting in practice.
Alive: https://alive2.llvm.org/ce/z/R5ZGSW
|
|
We already dereference the CxtI pointer several times before reaching the "if(CxtI)", we have no need to check it again.
Fixes a coverity warning.
|
|
Stop using APInt constructors and methods that were soft-deprecated in
D109483. This fixes all the uses I found in llvm, except for the APInt
unit tests which should still test the deprecated methods.
Differential Revision: https://reviews.llvm.org/D110807
|
