| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 279937
|
| |
|
|
|
|
|
|
| |
Like other recent changes near here, the goal is to allow vector types for
all of these folds. Splitting things up makes it easier to incrementally
enhance the code and easier to read.
llvm-svn: 279851
|
| |
|
|
|
|
|
|
| |
1. Early exit to reduce indent
2. Fix comments and variable names to match
3. Reformat comments / clang-format code
llvm-svn: 279837
|
| |
|
|
| |
llvm-svn: 279834
|
| |
|
|
| |
llvm-svn: 279831
|
| |
|
|
|
|
|
|
|
|
|
| |
Removing the redundant 'CmpRHSV' local variable exposes a bug in the caller
foldICmpShrConstant() - it was sending in the div constant instead of the
cmp constant. But I have not been able to expose this in a regression test
yet - the affected folds all appear to be handled before we ever reach this
code. I'll keep trying to find a case as I make changes to allow vector folds
in both functions.
llvm-svn: 279828
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D23590
llvm-svn: 279693
|
| |
|
|
|
|
|
|
|
| |
foldICmpDivConstant(); NFCI
There was no logic in foldICmpDivConstant, so no need for a separate function.
The code is directly copy/pasted, so further cleanups to follow.
llvm-svn: 279685
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 279677
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r279568; NFC
I deleted a fold from InstCombine at:
https://reviews.llvm.org/rL279568
because it (like any InstCombine to a constant?) should always happen in InstSimplify,
however, it's not obvious what the assumptions are in the remaining code.
Add a comment and assert to make it clearer.
Differential Revision: https://reviews.llvm.org/D23819
llvm-svn: 279626
|
| |
|
|
| |
llvm-svn: 279578
|
| |
|
|
|
|
|
| |
There will only be 3 lines of code in foldICmpShrConst() when the cleanup is done,
so it doesn't make much sense to have a separate function for a single fold.
llvm-svn: 279575
|
| |
|
|
|
|
|
|
| |
AFAICT, these already worked in all cases for scalar types, and I enhanced
the code to work for vector types in:
https://reviews.llvm.org/rL279543
llvm-svn: 279568
|
| |
|
|
|
|
|
|
| |
helpers; NFCI
This saves some casting in the helper functions and eases some further refactoring.
llvm-svn: 279478
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 279472
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: We can allow sinking if the single user block has only one unique predecessor, regardless of the number of edges. Note that a switch statement with multiple cases can have the same destination.
Reviewers: mcrosier, majnemer, spatel, reames
Subscribers: reames, mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D23722
llvm-svn: 279448
|
| |
|
|
|
|
|
|
|
|
|
| |
constant vectors, part 4
This concludes the fixes for icmp+shl in this series:
https://reviews.llvm.org/rL279339
https://reviews.llvm.org/rL279398
https://reviews.llvm.org/rL279399
llvm-svn: 279401
|
| |
|
|
|
|
|
|
| |
constant vectors, part 3
This is a partial enablement (move the ConstantInt guard down).
llvm-svn: 279399
|
| |
|
|
|
|
|
|
| |
constant vectors, part 2
This is a partial enablement (move the ConstantInt guard down).
llvm-svn: 279398
|
| |
|
|
|
|
|
|
| |
The callers still have ConstantInt guards, so there is no functional change
intended from this change. But relaxing the callers will allow more folds
for vector types.
llvm-svn: 279396
|
| |
|
|
|
|
|
|
|
| |
constant vectors, part 1
This is a partial enablement (move the ConstantInt guard down) because there are many
different folds here and one of the later ones will require reworking 'isSignBitCheck'.
llvm-svn: 279339
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Specifically, this is done near the end of "SimplifyICmpInst" using
computeKnownBits() as the broader solution. There are even vector
tests (yay!) for this in test/Transforms/InstSimplify/compare.ll.
I considered putting an assert here instead of just deleting, but
then we could assert every possible fold in InstSimplify in
InstCombine, so...less is more?
llvm-svn: 279300
|
| |
|
|
| |
llvm-svn: 279282
|
| |
|
|
| |
llvm-svn: 279279
|
| |
|
|
|
|
|
|
|
|
|
| |
The intended transform is:
// Simplify icmp eq (or (ptrtoint P), (ptrtoint Q)), 0
// -> and (icmp eq P, null), (icmp eq Q, null).
P and Q are both pointer types, but may have different types. We need
two calls to getNullValue() to make the icmps.
llvm-svn: 279271
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 279266
|
| |
|
|
|
|
|
|
|
| |
Of course, we really need to refactor and fix all of the cmp predicates,
but this one is interesting because without it, we later perform an
information-losing transform of icmp (shl 1, Y), C, and we can't recover
the better fold.
llvm-svn: 279263
|