| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We would eventually catch these via demanded bits and computing known bits in InstCombine,
but I think it's better to handle the simple cases as soon as possible as a matter of efficiency.
This fold allows further simplifications based on distributed ops transforms. eg:
%a = lshr i8 %x, 7
%b = or i8 %a, 2
%c = and i8 %b, 1
InstSimplify can directly fold this now:
%a = lshr i8 %x, 7
Differential Revision: https://reviews.llvm.org/D33221
llvm-svn: 303213
|
|
|
|
| |
llvm-svn: 303127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These folds were introduced with https://reviews.llvm.org/rL127064 as part of solving:
https://bugs.llvm.org/show_bug.cgi?id=9343
As shown here:
http://rise4fun.com/Alive/C8
...however, the sdiv exact case needs a stronger predicate.
I opted for duplicated code instead of adding another fallthrough because I think that's
easier to read (and edit in case we need/want to restrict/loosen the predicates any more).
This should fix:
https://bugs.llvm.org/show_bug.cgi?id=32949
https://bugs.llvm.org/show_bug.cgi?id=32948
Differential Revision: https://reviews.llvm.org/D32954
llvm-svn: 303104
|
|
|
|
|
|
|
|
| |
its commuted variants.
We already had (A & ~B) | (A ^ B), but we missed the cases where the not was part of the xor.
llvm-svn: 303004
|
|
|
|
| |
llvm-svn: 303003
|
|
|
|
|
|
|
| |
Surprisingly, I don't think these are redundant for InstSimplify.
They were just misplaced as InstCombine tests.
llvm-svn: 302684
|
|
|
|
| |
llvm-svn: 302374
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Re-applying r301766 with a fix to a typo and a regression test.
The log message for r301766 was:
==================================================================================
InstructionSimplify: Canonicalize shuffle operands. NFC-ish.
Summary:
Apply canonicalization rules:
1. Input vectors with no elements selected from can be replaced with undef.
2. If only one input vector is constant it shall be the second one.
This allows constant-folding to cover more ad-hoc simplifications that
were in place and avoid duplication for RHS and LHS checks.
There are more rules we may want to add in the future when we see a
justification. e.g. mask elements that select undef elements can be
replaced with undef.
==================================================================================
Reviewers: spatel, RKSimon
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32863
llvm-svn: 302373
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can simplify (or (icmp X, C1), (icmp X, C2)) to 'true' or 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 deleted code in instcombine was completely ignoring predicates with
mismatched signedness.
This is a follow-up to:
https://reviews.llvm.org/rL301260
https://reviews.llvm.org/D32143
llvm-svn: 302370
|
|
|
|
| |
llvm-svn: 302251
|
|
|
|
|
|
| |
These are the 'or' counterparts for the tests added with r300493.
llvm-svn: 302248
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sibling folds for 'and' with casts were added with https://reviews.llvm.org/rL273200.
This is a preliminary step for adding the 'or' variants for the folds added with https://reviews.llvm.org/rL301260.
The reason for the strange form with constant LHS in the 1st test is because there's another missing fold in that
case for the inverted predicate. That should be fixed when we add the ConstantRange functionality for 'or-of-icmps'
that already exists for 'and-of-icmps'.
I'm hoping to share more code for the and/or cases, so we won't have these differences. This will allow us to remove
code from InstCombine. It's also possible that we can remove some code here in InstSimplify. I think we have some
duplicated folds because patterns are not matched in a general way.
Differential Revision: https://reviews.llvm.org/D32876
llvm-svn: 302189
|
|
|
|
| |
llvm-svn: 302174
|
|
|
|
|
|
|
|
|
| |
This change caused buildbot failures, apparently because we're not
passing around types that InstSimplify is used to seeing. I'm not overly
familiar with InstSimplify, so I'm reverting this until I can figure out
what exactly is wrong.
llvm-svn: 301885
|
|
|
|
|
|
|
|
|
| |
In particular (since it wouldn't fit nicely in the summary):
(select (icmp eq V 0) P (getelementptr P V)) -> (getelementptr P V)
Differential Revision: https://reviews.llvm.org/D31435
llvm-svn: 301880
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Following the discussion in pr32486, adding the simplification:
shuffle %x, %y, undef -> undef
Reviewers: spatel, RKSimon, andreadb, davide
Reviewed By: spatel
Subscribers: jroelofs, davide, llvm-commits
Differential Revision: https://reviews.llvm.org/D32293
llvm-svn: 301764
|
|
|
|
| |
llvm-svn: 301337
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
We simplify based on range intersection, but we're missing folds.
llvm-svn: 300493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 299984
|
|
|
|
|
|
| |
just scalar i1.
llvm-svn: 299665
|
|
|
|
|
|
| |
can simplify in one direction but not the other.
llvm-svn: 299627
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Test case shows opportunity to constant fold a shuffle with one variable
input vector operand.
llvm-svn: 299327
|
|
|
|
|
|
| |
Also, add a helper function so we don't have to repeat this code for each binop.
llvm-svn: 299309
|
|
|
|
| |
llvm-svn: 299308
|
|
|
|
|
|
|
| |
Adding some test-cases demonstrating cases that need to be improved.
To be followed by patches that improve these cases.
llvm-svn: 299189
|
|
|
|
| |
llvm-svn: 297411
|
|
|
|
|
|
|
|
| |
Follow-up for:
https://reviews.llvm.org/D30665
https://reviews.llvm.org/rL297390
llvm-svn: 297409
|
|
|
|
| |
llvm-svn: 297407
|
|
|
|
|
|
|
|
|
|
|
| |
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: 297048
|
|
|
|
| |
llvm-svn: 297040
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 295572
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
The comment was added with:
https://reviews.llvm.org/rL293773
...but there would be a cost to implement this and possibly no payoff.
llvm-svn: 293823
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A program may contain llvm.assume info that disagrees with other analysis.
This may be caused by UB in the program, so we must not crash because of that.
As noted in the code comments:
https://llvm.org/bugs/show_bug.cgi?id=31809
...we can do better, but this at least avoids the assert/crash in the bug report.
Differential Revision: https://reviews.llvm.org/D29395
llvm-svn: 293773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously we assumed that the result of sqrt(x) always had 0 as its
sign bit. But sqrt(-0) == -0.
Reviewers: hfinkel, efriedma, sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28928
llvm-svn: 293115
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 292841
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D28780
llvm-svn: 292233
|
|
|
|
| |
llvm-svn: 291970
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
eliminate the select
This is a limited solution for PR31512:
https://llvm.org/bugs/show_bug.cgi?id=31512
The motivation is that we will need to increase usage of llvm.assume and/or metadata to solve PR28430:
https://llvm.org/bugs/show_bug.cgi?id=28430
...and this kind of simplification is needed to take advantage of that extra information.
The 'not' test case would be handled by:
https://reviews.llvm.org/D28485
Differential Revision:
https://reviews.llvm.org/D28337
llvm-svn: 291915
|