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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284649 91177308-0d34-0410-b5e6-96231b3b80d8
The constant folder didn't know how to always fold bitcasts of constant integer
vectors. In particular, it was unable to handle the case where a constant vector
had some undef elements, and the resulting (i.e. bitcasted) vector type had more
elements than the original vector type.
Example:
%cast = bitcast <2 x i64><i64 undef, i64 2> to <4 x i32>
On a little endian target, %cast could have been folded to:
<4 x i32><i32 undef, i32 undef, i32 2, i32 0>
This patch improves the folding logic by teaching how to correctly propagate
undef elements in the folded vector.
Differential Revision: https://reviews.llvm.org/D24301
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281343 91177308-0d34-0410-b5e6-96231b3b80d8
InstSimplify doesn't always know how to fold a bitcast of a constant vector.
In particular, the logic in InstSimplify doesn't know how to handle the case
where the constant vector in input contains some undef elements, and the
number of elements is smaller than the number of elements of the bitcast
vector type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281332 91177308-0d34-0410-b5e6-96231b3b80d8
Two tests have been merged together, regenerated and then moved to
a more appropriate directory. No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280814 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280488 91177308-0d34-0410-b5e6-96231b3b80d8
These folds already have tests for scalar and vector types, except
for the vector div-by-0 case, so I'm adding tests for that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280115 91177308-0d34-0410-b5e6-96231b3b80d8
...because like the corresponding code, this is just too big to keep adding to.
And the next step is to add a vector version of each of these tests to show
missed folds.
Also, auto-generate CHECK lines and add comments for the tests that correspond to
the source code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279530 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277738 91177308-0d34-0410-b5e6-96231b3b80d8
ConstantExpr::getWithOperands does much of the hard work that
ConstantFoldInstOperandsImpl tries to do but more completely.
This lets us fold ExtractValue/InsertValue expressions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277100 91177308-0d34-0410-b5e6-96231b3b80d8
When folding an expression, we run ConstantFoldConstantExpression on
each operand of that expression.
However, ConstantFoldConstantExpression can fail and retur nullptr.
Previously, we would bail on further refining the expression.
Instead, use the original operand and see if we can refine a later
operand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276959 91177308-0d34-0410-b5e6-96231b3b80d8
Failures in ConstantFoldConstantExpressionImpl were ignored causing
crashes down the line.
This fixes PR28725.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276827 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276341 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275379 91177308-0d34-0410-b5e6-96231b3b80d8
Treat loads which clip before the start of a global initializer the same
way we treat clipping beyond the end of the initializer: use zeros.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275345 91177308-0d34-0410-b5e6-96231b3b80d8
This is similar to the computeKnownBits improvement in rL268479.
There's probably more we can do for vector logic instructions, but
this should let us see non-splat constant masking ops that can
become vector selects instead of and/andn/or sequences.
Differential Revision: http://reviews.llvm.org/D21610
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273459 91177308-0d34-0410-b5e6-96231b3b80d8
Similar in spirit to D20497 :
If all elements of a constant vector are known non-zero, then we can say that the
whole vector is known non-zero.
It seems like we could extend this to FP scalar/vector too, but isKnownNonZero()
says it only works for integers and pointers for now.
Differential Revision: http://reviews.llvm.org/D20544
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270562 91177308-0d34-0410-b5e6-96231b3b80d8
