| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
This generates invalid IR: the only users of swifterror can be call
arguments, loads, and stores.
rdar://28242257
llvm-svn: 281144
|
| |
|
|
|
|
| |
vectors
llvm-svn: 281107
|
| |
|
|
|
|
|
| |
I was looking to fix a bug in getComplexity(), and these cases showed up as
obvious failures. I'm not sure how to find these in general though.
llvm-svn: 281055
|
| |
|
|
| |
llvm-svn: 280993
|
| |
|
|
| |
llvm-svn: 280991
|
| |
|
|
| |
llvm-svn: 280960
|
| |
|
|
| |
llvm-svn: 280959
|
| |
|
|
| |
llvm-svn: 280957
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Two tests have been merged together, regenerated and then moved to
a more appropriate directory. No functional change.
llvm-svn: 280814
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
The script (utils/update_test_checks.py) seems to have problems
with variable names that start with the same string.
llvm-svn: 280679
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This allows more of the OCML builtin library to be
constant folded.
llvm-svn: 280586
|
| |
|
|
|
|
| |
Add -mtriple=x86_64-unknown-linux-gnu for the test and move it to CodeGen/X86.
llvm-svn: 280568
|
| |
|
|
| |
llvm-svn: 280531
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the store of a wide value merged from a pair of values, especially int-fp pair,
sometimes it is more efficent to split it into separate narrow stores, which can
remove the bitwise instructions or sink them to colder places.
Now the feature is only enabled on x86 target, and only store of int-fp pair is
splitted. It is possible that the application scope gets extended with perf evidence
support in the future.
Differential Revision: https://reviews.llvm.org/D22840
llvm-svn: 280505
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Added a tests that shows that several insertelementinsts with constant
indexes/data are not folded into a single shuffleinst.
llvm-svn: 280474
|
| |
|
|
| |
llvm-svn: 280403
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 280175
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 279937
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D23590
llvm-svn: 279693
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 279677
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 279400
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 279259
|
| |
|
|
|
|
|
| |
These are implicitly included as part of larger test cases, but they don't
exist stand-alone (and don't happen for vectors...).
llvm-svn: 279257
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Also add popcount(n) == bitsize(n) -> n == -1 transformation.
Reviewers: majnemer, spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23134
llvm-svn: 279141
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
constant vectors
This is a sibling of:
https://reviews.llvm.org/rL278859
https://reviews.llvm.org/rL278935
https://reviews.llvm.org/rL278945
https://reviews.llvm.org/rL279066
https://reviews.llvm.org/rL279077
https://reviews.llvm.org/rL279101
llvm-svn: 279133
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
constant vectors
This is a sibling of:
https://reviews.llvm.org/rL278859
https://reviews.llvm.org/rL278935
https://reviews.llvm.org/rL278945
https://reviews.llvm.org/rL279066
https://reviews.llvm.org/rL279077
llvm-svn: 279101
|
| |
|
|
|
|
|
|
|
|
|
|
| |
constant vectors
This is a sibling of:
https://reviews.llvm.org/rL278859
https://reviews.llvm.org/rL278935
https://reviews.llvm.org/rL278945
https://reviews.llvm.org/rL279066
llvm-svn: 279077
|
| |
|
|
|
|
|
|
|
|
|
| |
constant vectors
This is a sibling of:
https://reviews.llvm.org/rL278859
https://reviews.llvm.org/rL278935
https://reviews.llvm.org/rL278945
llvm-svn: 279066
|
| |
|
|
|
|
|
|
| |
Also, add a scalar test to demonstrate one of the intermediate folds that
is necessary to accomplish the existing, multi-step test. And simplify
the vector tests to only check the final piece of that multi-step transform.
llvm-svn: 278995
|