| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simplify* arguments.
Summary:
Expose the internal query structure, start using it.
Note: This is the most minimal change possible i could create. I have
trivial followups, like fixing the one use of const FastMathFlags &,
the renaming of CtxI to be consistent, etc.
This should be NFC.
Reviewers: majnemer, davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32448
llvm-svn: 301379
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
temporary APInts
This patch uses various APInt methods to reduce temporary APInt creation.
This should be all of the unrelated cleanups that got buried in D32376(creating a KnownBits struct) as well as some pointed out by Simon during the review of that. Plus a few improvements to use counting instead of masking.
I've left out any places where we do something like (KnownZero & KnownOne) != 0 as I plan to add a helper method to KnownBits to ask that question and didn't want to thrash that code an additional time.
Differential Revision: https://reviews.llvm.org/D32495
llvm-svn: 301338
|
| |
|
|
|
|
|
|
|
|
| |
The code Sanjay Patel moved over from InstCombine doesn't work properly if the 'and' has both inputs as nots because we used a commuted op matcher on the 'and' first. But this will bind to the first 'not' on 'and' when there could be two 'not's. InstCombine could rely on DeMorgan to ensure the 'and' wouldn't have two 'not's eventually, but InstSimplify can't rely on that.
This patch matches the xor first then checks for the ands and allows a not of either operand of the xor.
Differential Revision: https://reviews.llvm.org/D32458
llvm-svn: 301329
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We can simplify (and (icmp X, C1), (icmp X, C2)) to one of the icmps in many cases.
I had to check some of these with Alive to prove to myself it's right, but everything
seems to check out. Eg, the code in instcombine was completely ignoring predicates with
mismatched signedness.
Handling or-of-icmps would be a follow-up step.
Differential Revision: https://reviews.llvm.org/D32143
llvm-svn: 301260
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a straight cut and paste, but there's a bigger problem: if this
fold exists for simplifyOr, there should be a DeMorganized version for
simplifyAnd. But more than that, we have a patchwork of ad hoc logic
optimizations in InstCombine. There should be some structure to ensure
that we're not missing sibling folds across and/or/xor.
llvm-svn: 301213
|
| |
|
|
|
|
|
|
| |
getSignBit is a static function that creates an APInt with only the sign bit set. getSignMask seems like a better name to convey its functionality. In fact several places use it and then store in an APInt named SignMask.
Differential Revision: https://reviews.llvm.org/D32108
llvm-svn: 300856
|
| |
|
|
|
|
|
|
|
|
| |
overflow bool out param is used.
This is preparation for a clang change to improve the [[nodiscard]] warning to not be ignored on methods that return a class marked [[nodiscard]] that are defined in the class itself. See D32207.
We should consider adding wrapper methods to APInt that return the overflow flag directly and discard the APInt result. This would eliminate the void casts and the need to create a bool before the call to pass to the out param.
llvm-svn: 300758
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch simplifies the examples from D31509 and D31927 (PR30630) and catches
the basic identity shuffle tests that Zvi recently added.
I'm not sure if we have something like this in DAGCombiner, but we should?
It's worth noting that "MaxRecurse / RecursionLimit" is only 3 on entry at the moment.
We might want to bump that up if there are longer shuffle chains like this in the wild.
For now, we're ignoring shuffles that have undef mask elements because it's not
clear how those should be handled.
Differential Revision: https://reviews.llvm.org/D31960
llvm-svn: 300714
|
| |
|
|
|
|
|
|
|
|
| |
InstSimplify returned the wrong type when simplifying a vector GEP
and we ended up crashing when trying to replace all uses with the
new value. Fixes PR32697.
Differential Revision: https://reviews.llvm.org/D32180
llvm-svn: 300693
|
| |
|
|
|
|
|
|
| |
The ConstantInt version has the same assert, and using null/allOnes is likely less efficient.
The only advantage of these local variants (and there's probably a better way to achieve this?)
is to save typing "ConstantInt::" over and over.
llvm-svn: 300426
|
| |
|
|
|
|
|
|
| |
anything.
Should give a small compile time improvement.
llvm-svn: 300125
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fold:
shuffle (splat-shuffle), undef, M --> splat-shuffle
Reviewers: spatel, RKSimon, craig.topper
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31527
llvm-svn: 299990
|
| |
|
|
| |
llvm-svn: 299870
|
| |
|
|
|
|
| |
function operands to remove some casts. NFC
llvm-svn: 299745
|
| |
|
|
|
|
| |
We have dedicated handlers for every opcode so nothing can get here anymore. The switch doesn't get detected as fully covered because Opcode is an unsigned. Casting to Instruction::BinaryOps still doesn't detect it because BinaryOpsEnd is in the enum and 1 past the last opcode.
llvm-svn: 299687
|
| |
|
|
|
|
| |
just scalar i1.
llvm-svn: 299665
|
| |
|
|
|
|
| |
can be treated as Xor too.
llvm-svn: 299626
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add a hook for simplification of shufflevector's with the following rules:
- Constant folding - NFC, as it was already being done by the default handler.
- If only one of the operands is constant, constant fold the shuffle if the
mask does not select elements from the variable operand - to show the hook is firing and affecting the test-cases.
Reviewers: RKSimon, craig.topper, spatel, sanjoy, nlopes, majnemer
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31525
llvm-svn: 299393
|
| |
|
|
|
|
| |
Also, add a helper function so we don't have to repeat this code for each binop.
llvm-svn: 299309
|
| |
|
|
| |
llvm-svn: 299307
|
| |
|
|
|
|
| |
m_Specific. NFCI
llvm-svn: 299121
|
| |
|
|
|
|
| |
~APInt::getSignBit. NFC
llvm-svn: 299120
|
| |
|
|
| |
llvm-svn: 297411
|
| |
|
|
|
|
|
|
|
|
|
| |
This was suggested as a DAG simplification in the review for rL297026 :
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170306/435253.html
...but let's start with IR since we have actual docs for IR (LangRef).
Differential Revision:
https://reviews.llvm.org/D30665
llvm-svn: 297390
|
| |
|
|
| |
llvm-svn: 297052
|
| |
|
|
|
|
| |
Div/rem-of-0 does not cause faults/undef (not the same as div/rem-by-0).
llvm-svn: 297029
|
| |
|
|
|
|
|
|
|
| |
The change to InstCombine in:
https://reviews.llvm.org/D29729
...exposes this missing fold in InstSimplify, so adding this
first to avoid a regression.
llvm-svn: 295573
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|