| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
When an aggregate contains an opaque type its size cannot be
determined. This triggers an "Invalid GetElementPtrInst indices for type" assert
in function checkGEPType. The fix suppresses the conversion in this case.
http://reviews.llvm.org/D20319
llvm-svn: 270479
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
vector splat constants
We could try harder to handle non-splat vector constants too,
but that seems much rarer to me.
Note that the div test isn't resolved because there's a check
for isIntegerTy() guarding that transform.
Differential Revision: http://reviews.llvm.org/D20497
llvm-svn: 270369
|
| |
|
|
|
|
|
| |
This should not be making assumptions on the value of
the casted pointer.
llvm-svn: 270293
|
| |
|
|
| |
llvm-svn: 270285
|
| |
|
|
| |
llvm-svn: 270284
|
| |
|
|
| |
llvm-svn: 270271
|
| |
|
|
| |
llvm-svn: 270265
|
| |
|
|
|
|
|
|
|
|
| |
address and result of load instructions
This patch fixes https://llvm.org/bugs/show_bug.cgi?id=27703.
If there is a sequence of one or more load instructions, each loaded value is used as address of later load instruction, bitcast is necessary to change the value type, don't optimize it.
llvm-svn: 270135
|
| |
|
|
|
|
| |
It doesn't matter if the comparison is unsigned; the inc/dec is always signed.
llvm-svn: 269831
|
| |
|
|
|
|
| |
The code fix for this was checked in at r269797.
llvm-svn: 269803
|
| |
|
|
|
|
| |
Fixes PR27786.
llvm-svn: 269757
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
icmp (PR27756)
Fix a bug introduced with rL269426 :
[InstCombine] canonicalize* LE/GE vector integer comparisons to LT/GT (PR26701, PR26819)
We were assuming that a ConstantDataVector / ConstantVector / ConstantAggregateZero operand of
an ICMP was composed of ConstantInt elements, but it might have ConstantExpr or UndefValue
elements. Handle those appropriately.
Also, refactor this function to join the scalar and vector paths and eliminate the switches.
Differential Revision: http://reviews.llvm.org/D20289
llvm-svn: 269728
|
| |
|
|
| |
llvm-svn: 269449
|
| |
|
|
| |
llvm-svn: 269447
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Enhancement to: http://reviews.llvm.org/rL269426
With discussion in: http://reviews.llvm.org/D17859
This should complete the fixes for: PR26701, PR26819:
https://llvm.org/bugs/show_bug.cgi?id=26701
https://llvm.org/bugs/show_bug.cgi?id=26819
llvm-svn: 269439
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR26701, PR26819)
*We don't currently handle the edge case constants (min/max values), so it's not a complete
canonicalization.
To fully solve the motivating bugs, we need to enhance this to recognize a zero vector
too because that's a ConstantAggregateZero which is a ConstantData, not a ConstantVector
or a ConstantDataVector.
Differential Revision: http://reviews.llvm.org/D17859
llvm-svn: 269426
|
| |
|
|
|
|
|
|
|
|
| |
This patch adds support for two optimizations:
icmp ugt (udiv C2, X), C1 -> icmp ule X, C2/(C1+1)
icmp ult (udiv C2, X), C1 -> icmp ugt X, C2/C1
Differential Revision: http://reviews.llvm.org/D20123
llvm-svn: 269109
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When a va_start or va_copy is immediately followed by a va_end (ignoring
debug information or other start/end in between), then it is safe to
remove the pair. As this code shares some commonalities with the lifetime
markers, this has been factored to helper functions.
This InstCombine pattern kicks-in 3 times when running the LLVM test
suite.
llvm-svn: 269033
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20036
llvm-svn: 268960
|
| |
|
|
| |
llvm-svn: 268922
|
| |
|
|
|
|
|
|
|
|
|
| |
Original Commit Message
Extend load/store type canonicalization to handle unordered operations
Extend the type canonicalization logic to work for unordered atomic loads and stores. Note that while this change itself is fairly simple and low risk, there's a reasonable chance this will expose problems in the backends by suddenly generating IR they wouldn't have seen before. Anything of this nature will be an existing bug in the backend (you could write an atomic float load), but this will definitely change the frequency with which such cases are encountered. If you see problems, feel free to revert this change, but please make sure you collect a test case.
Note that the concern about lowering is now much less likely. PR27490 proved that we already *were* mucking with the types of ordered atomics and volatiles. As a result, this change doesn't introduce as much new behavior as originally thought.
llvm-svn: 268809
|
| |
|
|
| |
llvm-svn: 268636
|
| |
|
|
|
|
|
|
|
| |
dominating conditions.""
This reapplies commit r268521, that was reverted in r268530 due to a test failure in select-implied.ll
Modified the test case to reflect the new change.
llvm-svn: 268557
|
| |
|
|
|
|
|
|
| |
conditions."
This reverts commit 573a40f79b35cf3e71db331bb00f6a84f03b835d.
llvm-svn: 268530
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch canonicalizes conditions based on the constant range information
of the dominating branch condition.
For example:
%cmp = icmp slt i64 %a, 0
br i1 %cmp, label %land.lhs.true, label %lor.rhs
lor.rhs:
%cmp2 = icmp sgt i64 %a, 0
Would now be canonicalized into:
%cmp = icmp slt i64 %a, 0
br i1 %cmp, label %land.lhs.true, label %lor.rhs
lor.rhs:
%cmp2 = icmp ne i64 %a, 0
Reviewers: mcrosier, gberry, t.p.northover, llvm-commits, reames, hfinkel, sanjoy, majnemer
Subscribers: MatzeB, majnemer, mcrosier
Differential Revision: http://reviews.llvm.org/D18841
llvm-svn: 268521
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConstantVector
We assumed that ConstantVectors would be rather uninteresting from the
perspective of analysis. However, this is not the case due to a quirk
of how LLVM handles vectors of i1. Vectors of i1 are not
ConstantDataVectors like vectors of i8, i16, i32 or i64 because i1's
SizeInBits differs from it's StoreSizeInBytes. This leads to it being
categorized as a ConstantVector instead of a ConstantDataVector.
Instead, treat ConstantVector more uniformly.
This fixes PR27591.
llvm-svn: 268479
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary
When a non-escaping pointer is compared to a global value, the
comparison can be folded even if the corresponding malloc/allocation
call cannot be elided.
We need to make sure the global value is not null, since comparisons to
null cannot be folded.
In future, we should also handle cases when the the comparison
instruction dominates the pointer escape.
Reviewers: sanjoy
Subscribers s.egerton, llvm-commits
Differential Revision: http://reviews.llvm.org/D19549
llvm-svn: 268390
|
| |
|
|
| |
llvm-svn: 268246
|
| |
|
|
| |
llvm-svn: 268245
|
| |
|
|
| |
llvm-svn: 268244
|
| |
|
|
| |
llvm-svn: 268242
|
| |
|
|
| |
llvm-svn: 268241
|
| |
|
|
| |
llvm-svn: 268239
|
| |
|
|
| |
llvm-svn: 268232
|
| |
|
|
|
|
| |
accept UNDEF elements.
llvm-svn: 268206
|
| |
|
|
| |
llvm-svn: 268205
|
| |
|
|
|
|
| |
UNDEF elements.
llvm-svn: 268204
|
| |
|
|
|
|
| |
decode tests
llvm-svn: 268203
|
| |
|
|
|
|
| |
UNDEF elements.
llvm-svn: 268202
|
| |
|
|
| |
llvm-svn: 268201
|
| |
|
|
|
|
| |
shufflevector.
llvm-svn: 268199
|
| |
|
|
|
|
| |
For future support for VPERMD/VPERMPS to generic shuffles combines
llvm-svn: 268166
|
| |
|
|
|
|
| |
UNDEF mask elements
llvm-svn: 268159
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19550
llvm-svn: 268104
|
| |
|
|
|
|
|
|
|
|
|
|
| |
matchSelectPattern attempts to see through casts which mask min/max
patterns from being more obvious. Under certain circumstances, it would
misidentify a sequence of instructions as a min/max because it assumed
that folding casts would preserve the result. This is not the case for
floating point <-> integer casts.
This fixes PR27575.
llvm-svn: 268086
|
| |
|
|
| |
llvm-svn: 268061
|
| |
|
|
|
| |
FIXME: We currently don't support folding constant pshufb shuffle masks containing undef elements.
llvm-svn: 268016
|
| |
|
|
| |
llvm-svn: 268014
|
| |
|
|
|
|
|
|
|
|
| |
The MOVMSK instructions copies a vector elements' sign bits to the low bits of a scalar register and zeros the high bits.
This patch adds MOVMSK support to SimplifyDemandedUseBits so that its aware that the upper bits are known to be zero. It also removes the call to MOVMSK if none of the lower bits are actually required and just returns zero.
Differential Revision: http://reviews.llvm.org/D19614
llvm-svn: 267873
|
| |
|
|
|
|
| |
At the moment we don't simplify PSRAV/PSRLV/PSLLV intrinsics to generic IR for constant shift amounts, but we could.
llvm-svn: 267777
|