| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
from the end of two blocks, merge instead of arbitrarily picking one.
Differential Revision: http://reviews.llvm.org/D29504
llvm-svn: 294251
|
|
|
|
| |
llvm-svn: 294198
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is based on the llvm-dev discussion here:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/109631.html
Folding to i1 should always be desirable because that's better for value tracking
and we have special folds for i1 types.
I checked for other users of shouldChangeType() where this might have an effect,
but we already handle the i1 case differently than other types in all of those cases.
Side note: the default datalayout includes i1, so it seems we only find this gap in
shouldChangeType + phi folding for the case when there is (1) an explicit datalayout
without i1, (2) casting to i1 from a legal type, and (3) a phi with exactly 2 incoming
casted operands (as Björn mentioned).
Differential Revision: https://reviews.llvm.org/D29336
llvm-svn: 294066
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code comments didn't match the code logic, and we didn't actually distinguish the fake unary (not/neg/fneg)
operators from arguments. Adding another level to the weighting scheme provides more structure and can help
simplify the pattern matching in InstCombine and other places.
I fixed regressions that would have shown up from this change in:
rL290067
rL290127
But that doesn't mean there are no pattern-matching logic holes left; some combines may just be missing regression tests.
Should fix:
https://llvm.org/bugs/show_bug.cgi?id=28296
Differential Revision: https://reviews.llvm.org/D27933
llvm-svn: 294049
|
|
|
|
|
|
|
|
|
|
|
| |
Although this is 'no-functional-change-intended', I'm adding tests
for shl-shl and lshr-lshr pairs because there is no existing test
coverage for those folds.
It seems like we should be able to remove some code from foldShiftedShift()
at this point because we're handling those patterns on the general path.
llvm-svn: 293814
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If there are two adjacent guards with different conditions, we can
remove one of them and include its condition into the condition of
another one. This patch allows InstCombine to merge them by the
following pattern:
guard(a); guard(b) -> guard(a & b).
Reviewers: reames, apilipenko, igor-laevsky, anna, sanjoy
Reviewed By: sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29378
llvm-svn: 293778
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29314
llvm-svn: 293661
|
|
|
|
| |
llvm-svn: 293658
|
|
|
|
| |
llvm-svn: 293652
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
transformToIndexedCompare
If they don't have the same type, the size of the constant
index would need to be adjusted (and this wouldn't be always
possible).
Alternatively we could try the analysis with the initial
RHS value, which would guarantee that the two sides have
the same type. However it is unlikely that in practice this
would pass our transformation requirements.
Fixes PR31808 (https://llvm.org/bugs/show_bug.cgi?id=31808).
llvm-svn: 293629
|
|
|
|
|
|
| |
with splat constants
llvm-svn: 293570
|
|
|
|
|
|
| |
constants
llvm-svn: 293562
|
|
|
|
|
|
| |
vectors with splat constants
llvm-svn: 293524
|
|
|
|
| |
llvm-svn: 293508
|
|
|
|
|
|
| |
with splat constants
llvm-svn: 293507
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original shift is bigger, so this may qualify as 'obvious',
but here's an attempt at an Alive-based proof:
Name: exact
Pre: (C1 u< C2)
%a = shl i8 %x, C1
%b = lshr exact i8 %a, C2
=>
%c = lshr exact i8 %x, C2 - C1
%b = and i8 %c, ((1 << width(C1)) - 1) u>> C2
Optimization is correct!
llvm-svn: 293498
|
|
|
|
| |
llvm-svn: 293489
|
|
|
|
|
|
| |
with splats
llvm-svn: 293435
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inf-loop (PR31751)
This is a minimal patch to avoid the infinite loop in:
https://llvm.org/bugs/show_bug.cgi?id=31751
But the general problem is bigger: we're not canonicalizing all of the min/max forms reported
by value tracking's matchSelectPattern(), and we don't define min/max consistently. Some code
uses matchSelectPattern(), other code uses matchers like m_Umax, and others have their own
inline definitions which may be subtly different from any of the above.
The reason that the test cases in this patch need a cast op to trigger is because we don't
(yet) canonicalize all min/max forms based on matchSelectPattern() in
canonicalizeMinMaxWithConstant(), but we do make min/max+cast transforms based on
matchSelectPattern() in visitSelectInst().
The location of the icmp transforms that trigger the inf-loop seems arbitrary at best, so
I'm moving those behind the min/max fence in visitICmpInst() as the quick fix.
llvm-svn: 293345
|
|
|
|
| |
llvm-svn: 293253
|
|
|
|
|
|
| |
Introduced in r293244.
llvm-svn: 293251
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are many NVVM intrinsics that we can't entirely get rid of, but
that nonetheless often correspond to target-generic LLVM intrinsics.
For example, if flush denormals to zero (ftz) is enabled, we can convert
@llvm.nvvm.ceil.ftz.f to @llvm.ceil.f32. On the other hand, if ftz is
disabled, we can't do this, because @llvm.ceil.f32 will be lowered to a
non-ftz PTX instruction. In this case, we can, however, simplify the
non-ftz nvvm ceil intrinsic, @llvm.nvvm.ceil.f, to @llvm.ceil.f32.
These transformations are particularly useful because they let us
constant fold instructions that appear in libdevice, the bitcode library
that ships with CUDA and essentially functions as its libm.
Reviewers: tra
Subscribers: hfinkel, majnemer, llvm-commits
Differential Revision: https://reviews.llvm.org/D28794
llvm-svn: 293244
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change reverts:
r293061: "[InstCombine] Canonicalize guards for NOT OR condition"
r293058: "[InstCombine] Canonicalize guards for AND condition"
They miscompile cases like:
```
declare void @llvm.experimental.guard(i1, ...)
define void @test_guard_not_or(i1 %A, i1 %B) {
%C = or i1 %A, %B
%D = xor i1 %C, true
call void(i1, ...) @llvm.experimental.guard(i1 %D, i32 20, i32 30)[ "deopt"() ]
ret void
}
```
because they do transfer the `i32 20, i32 30` parameters to newly
created guard instructions.
llvm-svn: 293227
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already have this fold when the lshr has one use, but it doesn't need that
restriction. We may be able to remove some code from foldShiftedShift().
Also, move the similar:
(X << C) >>u C --> X & (-1 >>u C)
...directly into visitLShr to help clean up foldShiftByConstOfShiftByConst().
That whole function seems questionable since it is called by commonShiftTransforms(),
but there's really not much in common if we're checking the shift opcodes for every
fold.
llvm-svn: 293215
|
|
|
|
|
|
| |
splat vectors
llvm-svn: 293208
|
|
|
|
|
|
|
|
| |
This intrinsic uses bit 0 and bit 4 of an immediate argument to determine which bits of its inputs to read. This patch uses this information to simplify the demanded elements of the input vectors.
Differential Revision: https://reviews.llvm.org/D28979
llvm-svn: 293151
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial fix for Bug 31520 - [guards] canonicalize guards in instcombine
Reviewed By: apilipenko
Differential Revision: https://reviews.llvm.org/D29075
Patch by Maxim Kazantsev.
llvm-svn: 293061
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D28949
llvm-svn: 293060
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial fix for Bug 31520 - [guards] canonicalize guards in instcombine
Reviewed By: apilipenko
Differential Revision: https://reviews.llvm.org/D29074
Patch by Maxim Kazantsev.
llvm-svn: 293058
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
are equivalent
This is a partial fix for Bug 31520 - [guards] canonicalize guards in instcombine
Reviewed By: majnemer, apilipenko
Differential Revision: https://reviews.llvm.org/D29071
Patch by Maxim Kazantsev.
llvm-svn: 293056
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title. This will add the instructiions we are interested in in the worklist.
Reviewers: mehdi_amini, majnemer, andreadb
Differential Revision: https://reviews.llvm.org/D29081
llvm-svn: 292957
|
|
|
|
| |
llvm-svn: 292934
|
|
|
|
|
|
|
|
| |
Added early out for single undef input - we were already supporting (and testing) this in the constant folding code, we just do it quicker now
Drop undef handling from demanded elts code now that we handle it fully in InstCombiner::visitCallInst
llvm-svn: 292913
|
|
|
|
| |
llvm-svn: 292855
|
|
|
|
| |
llvm-svn: 292793
|
|
|
|
|
|
| |
Match generic mul behaviour so that <X x i64> multiply and muldq/muludq pattern act the same
llvm-svn: 292784
|
|
|
|
|
|
|
| |
We may be able to assert that no shl-shl or lshr-lshr pairs ever get here
because we should have already handled those in foldShiftedShift().
llvm-svn: 292726
|
|
|
|
| |
llvm-svn: 292627
|
|
|
|
|
|
|
|
| |
Simplify a packss/packus truncation based on the elements of the mask that are actually demanded.
Differential Revision: https://reviews.llvm.org/D28777
llvm-svn: 292591
|
|
|
|
|
|
|
|
| |
Patch by Andrea Canciani.
Differential Revision: https://reviews.llvm.org/D27413
llvm-svn: 292506
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Try harder to fold icmp with shl nsw as discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/108749.html
This is similar to the 'shl nuw' transforms that were added with D25913.
This may eventually help solve:
https://llvm.org/bugs/show_bug.cgi?id=30773
Differential Revision: https://reviews.llvm.org/D28406
llvm-svn: 292492
|
|
|
|
|
|
| |
explicit; NFCI
llvm-svn: 292440
|
|
|
|
|
|
|
| |
I missed deleting this check when I refactored this chunk in:
https://reviews.llvm.org/rL292260
llvm-svn: 292433
|
|
|
|
|
|
| |
Simplify a vpermv shuffle mask based on the elements of the mask that are actually demanded.
llvm-svn: 292371
|
|
|
|
|
|
| |
As discussed on D28777 - we don't need to handle 'all element' shuffles inside InstCombiner::visitCallInst as InstCombiner::SimplifyDemandedVectorElts will do everything we need.
llvm-svn: 292365
|
|
|
|
|
|
|
| |
This reduces the size of and increases the symmetry with the planned functional change in:
https://reviews.llvm.org/D28406
llvm-svn: 292260
|
|
|
|
|
|
|
| |
This further extends r292179 to support additional binary operators
beyond subtraction.
llvm-svn: 292238
|
|
|
|
| |
llvm-svn: 292230
|
|
|
|
|
|
|
|
| |
instructions
Simplify a vpermilvar shuffle mask based on the elements of the mask that are actually demanded.
llvm-svn: 292209
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Depends on D28740
Reviewers: dberlin, chandlerc, hfinkel, majnemer
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D28742
llvm-svn: 292197
|