| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to D29395 where we try to be good citizens and let the user know that
we've probably gone off the rails.
This should allow us to resolve:
https://llvm.org/bugs/show_bug.cgi?id=31809
Differential Revision: https://reviews.llvm.org/D29404
llvm-svn: 294208
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was surprised to see that we're missing icmp folds based on 'add nsw' in InstCombine,
but we should handle the InstSimplify cases first because that could make the InstCombine
code simpler.
Here are Alive-based proofs for the logic:
Name: add_neg_constant
Pre: C1 < 0 && (C2 > ((1<<(width(C1)-1)) + C1))
%a = add nsw i7 %x, C1
%b = icmp sgt %a, C2
=>
%b = false
Name: add_pos_constant
Pre: C1 > 0 && (C2 < ((1<<(width(C1)-1)) + C1 - 1))
%a = add nsw i6 %x, C1
%b = icmp slt %a, C2
=>
%b = false
Name: nuw
Pre: C1 u>= C2
%a = add nuw i11 %x, C1
%b = icmp ult %a, C2
=>
%b = false
Differential Revision: https://reviews.llvm.org/D29053
llvm-svn: 292952
|
|
|
|
| |
llvm-svn: 292812
|
|
|
|
|
|
|
|
| |
This fallthrough if other cases are added between fabs and default
could cause fabs to fall to the next case resulting in a bug.
Better getting rid of it immediately just to be sure.
llvm-svn: 292003
|
|
|
|
| |
llvm-svn: 291634
|
|
|
|
| |
llvm-svn: 291624
|
|
|
|
|
|
| |
We know that udiv %V, C can be optimized away to 0 if %V is ult C.
llvm-svn: 291296
|
|
|
|
|
|
| |
We know that urem %V, C can be optimized away to %V if %V is ult C.
llvm-svn: 291282
|
|
|
|
|
|
|
| |
This creates non-linear behavior in the inliner (see more details in
r289755's commit thread).
llvm-svn: 290086
|
|
|
|
|
|
|
|
|
| |
After r289755, the AssumptionCache is no longer needed. Variables affected by
assumptions are now found by using the new operand-bundle-based scheme. This
new scheme is more computationally efficient, and also we need much less
code...
llvm-svn: 289756
|
|
|
|
| |
llvm-svn: 289332
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D27587
llvm-svn: 289153
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As Eli noted in the post-commit thread for r288833, the use of
swapOperands() may not be allowed in InstSimplify, so I'm
removing those calls here pending further review.
The swap mutates the icmp, and there doesn't appear to be precedent
for instruction mutation in InstSimplify.
I didn't actually have any tests for those cases, so I'm adding
a few here.
llvm-svn: 288855
|
|
|
|
|
|
|
|
|
|
|
| |
All of these (and a few more) are already handled by InstCombine,
but we shouldn't have to wait until then to simplify these because
they're cheap to deal with here in InstSimplify.
This is the 'and' sibling of the earlier 'or' patch:
https://reviews.llvm.org/rL288833
llvm-svn: 288841
|
|
|
|
|
|
|
|
| |
All of these (and a few more) are already handled by InstCombine,
but we shouldn't have to wait until then to simplify these because
they're cheap to deal with here in InstSimplify.
llvm-svn: 288833
|
|
|
|
| |
llvm-svn: 288589
|
|
|
|
| |
llvm-svn: 288588
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Extends InstSimplify to handle both `x >=u x >> y` and `x >=u x udiv y`.
This is a folloup of rL258422 and
https://github.com/rust-lang/rust/pull/30917 where llvm failed to
optimize away the bounds checking in a binary search.
Patch by Arthur Silva!
Reviewers: sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25941
llvm-svn: 285228
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
0 - X --> X, if X is 0 or the minimum signed value
0 - X --> 0, if X is 0 or the minimum signed value and the sub is NSW
I noticed this pattern might be created in the backend after the change from D25485,
so we'll want to add a similar fold for the DAG.
The use of computeKnownBits in InstSimplify may be something to investigate if the
compile time of InstSimplify is noticeable. We could replace computeKnownBits with
specific pattern matchers or limit the recursion.
Differential Revision: https://reviews.llvm.org/D25785
llvm-svn: 284649
|
|
|
|
|
|
|
| |
ICmpInst::makeConstantRange does exactly the same thing as
ConstantRange::makeExactICmpRegion.
llvm-svn: 283059
|
|
|
|
| |
llvm-svn: 282592
|
|
|
|
| |
llvm-svn: 282590
|
|
|
|
| |
llvm-svn: 281972
|
|
|
|
|
|
|
| |
We don't need to call `GetCompareTy(LHS)' every single time true or false is
returned from function SimplifyFCmpInst as suggested by Sanjay in review D24142.
llvm-svn: 280491
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NaN.
This patch fixes a crash caused by an incorrect folding of an ordered comparison
between a packed floating point vector and a splat vector of NaN.
An ordered comparison between a vector and a constant vector of NaN, should
always be folded into a constant vector where each element is i1 false.
Since revision 266175, SimplifyFCmpInst folds the ordered fcmp into a scalar
'false'. Later on, this would cause an assertion failure, since the value type
of the folded value doesn't match the expected value type of the uses of the
original instruction: "Assertion failed: New->getType() == getType() &&
"replaceAllUses of value with new value of different type!".
This patch fixes the issue and adds a test case to the already existing test
InstSimplify/floating-point-compares.ll.
Differential Revision: https://reviews.llvm.org/D24143
llvm-svn: 280488
|
|
|
|
|
|
|
|
|
|
|
|
| |
Completes the m_APInt changes for simplifyICmpWithConstant().
Other commits in this series:
https://reviews.llvm.org/rL279492
https://reviews.llvm.org/rL279530
https://reviews.llvm.org/rL279534
https://reviews.llvm.org/rL279538
llvm-svn: 279543
|
|
|
|
| |
llvm-svn: 279538
|
|
|
|
|
|
|
|
|
| |
And add a FIXME because the helper excludes folds for vectors. It's
not clear yet how many of these are actually testable (and therefore
necessary?) because later analysis uses computeKnownBits and other
methods to catch many of these cases.
llvm-svn: 279492
|
|
|
|
|
|
|
| |
This is a mechanical change of comments in switches like fallthrough,
fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead.
llvm-svn: 278902
|
|
|
|
| |
llvm-svn: 278779
|
|
|
|
|
|
| |
No functionality change is intended.
llvm-svn: 278417
|
|
|
|
| |
llvm-svn: 277952
|
|
|
|
|
|
|
| |
Simplify ptrtoint comparisons involving operands with different source
types.
llvm-svn: 277951
|
|
|
|
|
|
|
|
|
| |
constant vectors
I'm removing a misplaced pair of more specific folds from InstCombine in this patch as well,
so we know where those folds are happening in InstSimplify.
llvm-svn: 277738
|
|
|
|
|
|
|
| |
This reinstates r277611 + r277614 and reverts r277642. A cast_or_null
should have been a dyn_cast_or_null.
llvm-svn: 277691
|
|
|
|
|
|
|
|
|
| |
This reverts commit r277611 and the followup r277614.
Bootstrap builds and chromium builds are crashing during inlining after
this change.
llvm-svn: 277642
|
|
|
|
|
|
|
|
|
|
|
| |
We were able to figure out that the result of a call is some constant.
While propagating that fact, we added the constant to the value map.
This is problematic because it results in us losing the call site when
processing the value map.
This fixes PR28802.
llvm-svn: 277611
|
|
|
|
|
|
| |
Use isEliminableCastPair to determine if a pair of casts are foldable.
llvm-svn: 276777
|
|
|
|
|
|
|
| |
This reverts commit r276700 and reapplies r276698.
The relevant clang tests have been updated.
llvm-svn: 276727
|
|
|
|
|
|
|
| |
This reverts commit r276698. Clang has tests which rely on the
optimizer :(
llvm-svn: 276700
|
|
|
|
|
|
|
| |
BitCasts of BitCasts can be folded away as can BitCasts which don't
change the type of the operand.
llvm-svn: 276698
|
|
|
|
|
|
| |
Truncates can completely cancel out a zext or sext instruction.
llvm-svn: 276604
|
|
|
|
| |
llvm-svn: 276345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
simplifications (PR28466)
rL245171 exposed a hole in InstSimplify that manifested in a strange way in PR28466:
https://llvm.org/bugs/show_bug.cgi?id=28466
It's possible to use trunc + icmp sgt/slt in place of an and + icmp eq/ne, so we need to
recognize that pattern to eliminate selects that are choosing between some value and some
bitmasked version of that value.
Note that there is significant room for improvement (refactoring) and enhancement (more
patterns, possibly in InstCombine rather than here).
Differential Revision: https://reviews.llvm.org/D22537
llvm-svn: 276341
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D22602
llvm-svn: 276209
|
|
|
|
| |
llvm-svn: 275911
|
|
|
|
|
|
|
| |
We can always pick the passthru value if the mask is undef: we are
permitted to treat the mask as-if it were filled with zeros.
llvm-svn: 275379
|
|
|
|
|
|
|
| |
This transform doesn't require any new instructions, it can safely live
in InstSimplify.
llvm-svn: 275344
|
|
|
|
|
|
|
|
|
| |
For functions which are known to return a specific argument, pointer-comparison
folding can look through the function calls as part of its analysis.
Differential Revision: http://reviews.llvm.org/D9387
llvm-svn: 275039
|