| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
The index of the new insertelement instruction was evaluated in the
wrong way, it was considered as the index of the inserted value instead
of index of the position, where the value should be inserted.
llvm-svn: 282401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes PR30366.
Function foldUDivShl() worked under the assumption that one of the values
in input to the function was always an instance of llvm::Instruction.
However, function visitUDivOperand() (the only user of foldUDivShl) was
clearly violating that precondition; internally, visitUDivOperand() uses pattern
matches to check the operands of a udiv. Pattern matchers for binary operators
know how to handle both Instruction and ConstantExpr values.
This patch fixes the problem in foldUDivShl(). Now we use pattern matchers
instead of explicit casts to Instruction. The reduced test case from PR30366
has been added to test file InstCombine/udiv-simplify.ll.
Differential Revision: https://reviews.llvm.org/D24565
llvm-svn: 282398
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If inserting more than one constant into a vector:
define <4 x float> @foo(<4 x float> %x) {
%ins1 = insertelement <4 x float> %x, float 1.0, i32 1
%ins2 = insertelement <4 x float> %ins1, float 2.0, i32 2
ret <4 x float> %ins2
}
InstCombine could reduce that to a shufflevector:
define <4 x float> @goo(<4 x float> %x) {
%shuf = shufflevector <4 x float> %x, <4 x float> <float undef, float 1.0, float 2.0, float undef>, <4 x i32><i32 0, i32 5, i32 6, i32 3>
ret <4 x float> %shuf
}
Also, InstCombine tries to convert shuffle instruction to single insertelement, if one of the vectors is a constant vector and only a single element from this constant should be used in shuffle, i.e.
shufflevector <4 x float> %v, <4 x float> <float undef, float 1.0, float
undef, float undef>, <4 x i32> <i32 0, i32 5, i32 undef, i32 undef> ->
insertelement <4 x float> %v, float 1.0, 1
Differential Revision: https://reviews.llvm.org/D24182
llvm-svn: 282237
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already have the udiv variant of this transform, so I think this is ok for
InstCombine too even though there is an increase in IR instructions. As the
tests and TODO comments show, the transform can lead to follow-on combines.
This should fix: https://llvm.org/bugs/show_bug.cgi?id=28672
Differential Revision: https://reviews.llvm.org/D24527
llvm-svn: 282209
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
shuffle
As discussed on llvm-dev ( http://lists.llvm.org/pipermail/llvm-dev/2016-August/104210.html ):
turn a vector select with constant condition operand into a shuffle as a canonicalization step.
Shuffles may be easier to reason about in conjunction with other shuffles and insert/extract.
Possible known (minor?) regressions from this change are filed as:
https://llvm.org/bugs/show_bug.cgi?id=28530
https://llvm.org/bugs/show_bug.cgi?id=28531
https://llvm.org/bugs/show_bug.cgi?id=30371
If something terrible happens to perf after this commit, feel free to revert until a backend
fix is in place.
Differential Revision: https://reviews.llvm.org/D24279
llvm-svn: 281787
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR24942)
computeKnownBits() already works for integer vectors, so allow vector types when calling that from InstCombine.
I don't think the change to use m_APInt in computeKnownBits is strictly necessary because we do check for
ConstantVector later, but it's more efficient to handle the splat case without needing to loop on vector elements.
This should work with InstSimplify, but doesn't yet, so I made that a FIXME comment on the test for PR24942:
https://llvm.org/bugs/show_bug.cgi?id=24942
Differential Revision: https://reviews.llvm.org/D24677
llvm-svn: 281777
|
|
|
|
| |
llvm-svn: 281743
|
|
|
|
|
|
| |
folds; NFCI
llvm-svn: 281672
|
|
|
|
|
|
|
|
|
|
|
|
| |
These 2 helper functions were already using APInt internally, so just
change the API and caller to allow folds for splats. The scalar
regression tests look quite thorough, so I just added a couple of
tests to prove that vectors are handled too.
These folds should be grouped with the other cmp+shift folds though.
That can be an NFC follow-up.
llvm-svn: 281663
|
|
|
|
|
|
|
|
| |
canRewriteGEPAsOffset expects to process instructions, not constants.
This fixes PR30342.
llvm-svn: 281650
|
|
|
|
| |
llvm-svn: 281644
|
|
|
|
| |
llvm-svn: 281637
|
|
|
|
|
|
| |
Also, clean up the code and comments for the existing folds in foldICmpSubConstant().
llvm-svn: 281631
|
|
|
|
|
|
|
|
|
|
|
| |
This pattern is matched in foldICmpBinOpEqualityWithConstant() and already works
with vectors too. I changed some comments over there to point out the current
location. The tests for this transform are currently in 'sub.ll'.
Note that the remaining folds in this block all require a sub too, so they should
get grouped with the other icmp(sub) patterns.
llvm-svn: 281627
|
|
|
|
| |
llvm-svn: 281624
|
|
|
|
|
|
|
|
| |
1. Early exit to reduce indent
2. Rename variables
3. Add local 'Pred' variable
llvm-svn: 281615
|
|
|
|
|
|
|
| |
This is a big glob of transforms that probably should work for vectors,
but currently they are disallowed because of ConstantInt guards.
llvm-svn: 281614
|
|
|
|
|
|
| |
constant vectors
llvm-svn: 281613
|
|
|
|
|
|
| |
The pattern matching and transforms are identical; the cmp predicate just changes.
llvm-svn: 281561
|
|
|
|
|
|
|
| |
This reapplies r272987 with a fix for infinitely looping
when the truncated value is another shift of a constant.
llvm-svn: 281379
|
|
|
|
|
|
| |
isSignBitCheck could be changed to take a pointer param to avoid the 'UnusedBit' ugliness.
llvm-svn: 281231
|
|
|
|
| |
llvm-svn: 281220
|
|
|
|
| |
llvm-svn: 281217
|
|
|
|
| |
llvm-svn: 281214
|
|
|
|
| |
llvm-svn: 281187
|
|
|
|
|
|
|
|
|
| |
This generates invalid IR: the only users of swifterror can be call
arguments, loads, and stores.
rdar://28242257
llvm-svn: 281144
|
|
|
|
|
|
|
|
|
| |
foldICmpIntrinsicWithConstant ; NFC
1. Rename variables to be consistent with related/preceding code (may want to reorganize).
2. Fix comments/formatting.
llvm-svn: 281140
|
|
|
|
|
|
|
|
|
|
| |
Everything under foldICmpInstWithConstant() should now be working for
splat vectors via m_APInt matchers. Ie, I've removed all of the FIXMEs
that I added while cleaning that section up. Note that not all of the
associated FIXMEs in the regression tests are gone though, because some
of the tests require earlier folds that are still scalar-only.
llvm-svn: 281139
|
|
|
|
|
|
| |
vectors
llvm-svn: 281107
|
|
|
|
|
|
|
|
|
|
|
| |
I introduced this potential bug by missing this diff in:
https://reviews.llvm.org/rL280873
...however, I'm not sure how to reach this code path with a regression test.
We may be able to remove this code and assume that the transform to a constant
is always handled by InstSimplify?
llvm-svn: 280964
|
|
|
|
|
|
| |
splat constant vectors
llvm-svn: 280873
|
|
|
|
|
|
|
|
| |
This is a revert of r280676 which was a revert of r280637;
ie, this is r280637 again. It was speculatively reverted to
help debug buildbot failures.
llvm-svn: 280861
|
|
|
|
|
|
|
|
|
|
|
| |
logic.
This fixes a similar issue to the one already fixed by r280804
(revieved in D24256). Revision 280804 fixed the problem with unsafe dyn_casts
in the extrq/extrqi combining logic. However, it turns out that even the
insertq/insertqi logic was affected by the same problem.
llvm-svn: 280807
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
operands of extrq/extrqi intrinsic calls.
This patch fixes an assertion failure caused by unsafe dynamic casts on the
constant operands of sse4a intrinsic calls to extrq/extrqi
The combine logic that simplifies sse4a extrq/extrqi intrinsic calls currently
checks if the input operands are constants. Internally, that logic relies on
dyn_casts of values returned by calls to method Constant::getAggregateElement.
However, method getAggregateElemet may return nullptr if the constant element
cannot be retrieved. So, all the dyn_casts can potentially fail. This is what
happens for example if a constexpr value is passed in input to an extrq/extrqi
intrinsic call.
This patch fixes the problem by using a dyn_cast_or_null (instead of a simple
dyn_cast) on the result of each call to Constant::getAggregateElement.
Added reproducible test cases to x86-sse4a.ll.
Differential Revision: https://reviews.llvm.org/D24256
llvm-svn: 280804
|
|
|
|
| |
llvm-svn: 280727
|
|
|
|
|
|
|
|
|
|
| |
This is effectively a revert of:
https://reviews.llvm.org/rL280115
And this should fix
https://llvm.org/bugs/show_bug.cgi?id=30281:
llvm-svn: 280677
|
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/14952/steps/ninja%20check%201/logs/FAIL%3A%20LLVM%3A%3Aicmp.ll
llvm-svn: 280676
|
|
|
|
|
|
|
|
| |
The code to calculate 'UsesRemoved' could be simplified.
As-is, that code is a victim of PR30273:
https://llvm.org/bugs/show_bug.cgi?id=30273
llvm-svn: 280637
|
|
|
|
|
|
|
|
|
|
|
| |
The transform in question:
icmp (and (trunc W), C2), C1 -> icmp (and W, C2'), C1'
...is still not enabled for vectors, thus no functional change intended.
It's not clear to me if this is a good transform for vectors or even
scalars in general. Changing that behavior may be a follow-on patch.
llvm-svn: 280627
|
|
|
|
|
|
|
|
|
|
|
|
| |
memcpy with ld/st.
When InstCombine replaces a memcpy with loads+stores it does not copy over the
llvm.mem.parallel_loop_access from the memcpy instruction. This patch fixes
that.
Differential Revision: https://reviews.llvm.org/D23499
llvm-svn: 280617
|
|
|
|
| |
llvm-svn: 280615
|
|
|
|
|
|
|
| |
This allows more of the OCML builtin library to be
constant folded.
llvm-svn: 280586
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
operand (PR29126)
The motivating case occurs with SSE/AVX scalar intrinsics, so this is a first step towards
shrinking that to a single shufflevector.
Note that the transform is intentionally limited to shuffles that are equivalent to vector
selects to avoid creating arbitrary shuffle masks that may not lower well.
This should solve PR29126:
https://llvm.org/bugs/show_bug.cgi?id=29126
Differential Revision: https://reviews.llvm.org/D23886
llvm-svn: 280504
|
|
|
|
|
|
|
|
|
|
|
|
| |
While removing a scalar shackle from an icmp fold, I noticed that I couldn't find any tests to trigger
this code path.
The 'and' shrinking transform should be handled by InstCombiner::foldCastedBitwiseLogic()
or eliminated with InstSimplify. The icmp narrowing is part of InstCombiner::foldICmpWithCastAndCast().
Differential Revision: https://reviews.llvm.org/D24031
llvm-svn: 280370
|
|
|
|
|
|
|
| |
The enhancement to foldICmpDivConstant ( http://llvm.org/viewvc/llvm-project?view=revision&revision=280299 )
allows us to remove the ConstantInt check; no other changes needed.
llvm-svn: 280300
|
|
|
|
|
|
| |
Converting all of the overflow ops to APInt looked risky, so I've left that as a TODO.
llvm-svn: 280299
|
|
|
|
|
|
|
|
| |
This is prep work before changing the callers to also use APInt which will
allow folds for splat vectors. Currently, the callers have ConstantInt
guards in place, so no functional change intended with this commit.
llvm-svn: 280282
|
|
|
|
|
|
|
|
|
|
| |
It's much less code and easier to read if we don't duplicate
everything between the 'Inside' and not 'Inside' cases.
As noted with the FIXME, the goal is to make this vector-friendly
in a follow-up patch.
llvm-svn: 280183
|
|
|
|
|
|
|
| |
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.
llvm-svn: 280115
|
|
|
|
|
|
|
|
| |
1. Fix comments to match variable names
2. Remove redundant CmpRHS variable
3. Add FIXME to replace some checks with asserts
llvm-svn: 280112
|