| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Currently foldSelectICmpAndOr asserts if the "or" involves a vector
containing several of the same power of two. We can easily avoid this by
only performing the fold on integer types, like foldSelectICmpAnd does.
Fixes <rdar://problem/15012516>
llvm-svn: 191552
|
|
|
|
|
|
|
|
|
| |
don't match.
Inserting a zext or trunc is sufficient. This pattern is somewhat common in
LLVM's pointer mangling code.
llvm-svn: 185270
|
|
|
|
|
|
| |
Thanks Nick Lewycky for pointing this out.
llvm-svn: 181177
|
|
|
|
|
|
|
| |
Differences in bitwidth between X and Y could exist even if C1 and C2 have
the same Log2 representation.
llvm-svn: 180779
|
|
|
|
|
|
|
|
|
| |
This fixes the optimization introduced in r179748 and reverted in r179750.
While the optimization was sound, it did not properly respect differences in
bit-width.
llvm-svn: 180777
|
|
|
|
| |
llvm-svn: 179826
|
|
|
|
|
|
| |
It is causing stage2 builds to fail, let's get them running again.
llvm-svn: 179750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Simplify:
(select (icmp eq (and X, C1), 0), Y, (or Y, C2))
Into:
(or (shl (and X, C1), C3), y)
Where:
C3 = Log(C2) - Log(C1)
If:
C1 and C2 are both powers of two
llvm-svn: 179748
|
|
|
|
| |
llvm-svn: 178915
|
|
|
|
| |
llvm-svn: 178208
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
|
|
|
|
| |
ConstantFoldInstOperands and crash.
Have to refactor the ConstantFolder interface one day to define bugs like this away. Fixes PR14131.
llvm-svn: 166374
|
|
|
|
| |
llvm-svn: 165402
|
|
|
|
| |
llvm-svn: 164814
|
|
|
|
| |
llvm-svn: 164763
|
|
|
|
|
|
|
|
| |
self-referencing select inst.
This can happen as long as the instruction is not reachable. Instcombine does generate these unreachable malformed selects when doing RAUW
llvm-svn: 160874
|
|
|
|
|
|
| |
vector
llvm-svn: 160835
|
|
|
|
|
|
| |
elements, which may disagree with the select condition type.
llvm-svn: 158166
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test case feeds the following into InstCombine's visitSelect:
%tobool8 = icmp ne i32 0, 0
%phitmp = select i1 %tobool8, i32 3, i32 0
Then instcombine replaces the right side of the switch with 0, doesn't notice
that nothing changes and tries again indefinitely.
This fixes PR12897.
llvm-svn: 157587
|
|
|
|
| |
llvm-svn: 148578
|
|
|
|
|
|
| |
These can be reduced to "~cond & x" or "~cond | x"
llvm-svn: 146624
|
|
|
|
|
|
| |
Add FIXMEs to places that are non-trivial to fix.
llvm-svn: 145661
|
|
|
|
|
|
| |
r140966.
llvm-svn: 140969
|
|
|
|
|
|
| |
but not load instructions. Noticed by inspection.
llvm-svn: 140966
|
|
|
|
|
|
| |
it's used and not included where it isn't.
llvm-svn: 135628
|
|
|
|
| |
llvm-svn: 135477
|
|
|
|
| |
llvm-svn: 135375
|
|
|
|
| |
llvm-svn: 133756
|
|
|
|
|
|
|
|
| |
instead.
Fixes PR10040.
llvm-svn: 132254
|
|
|
|
|
|
|
|
| |
trying instsimplify on the arm where we know the compared value.
Stuff like "x == y ? y : x&y" now folds into "x&y".
llvm-svn: 132185
|
|
|
|
| |
llvm-svn: 131547
|
|
|
|
| |
llvm-svn: 131544
|
|
|
|
| |
llvm-svn: 131542
|
|
|
|
| |
llvm-svn: 128413
|
|
|
|
|
|
| |
the subclass optional data.
llvm-svn: 128388
|
|
|
|
|
|
|
|
|
|
| |
removes one use of X which helps it pass the many hasOneUse() checks.
In my analysis, this turns up very often where X = A >>exact B and that can't be
simplified unless X has one use (except by increasing the lifetime of A which is
generally a performance loss).
llvm-svn: 128373
|
|
|
|
|
|
|
|
| |
it's a zero comparison when it's not.
Fixes PR9454.
llvm-svn: 127464
|
|
|
|
| |
llvm-svn: 124469
|
|
|
|
| |
llvm-svn: 123121
|
|
|
|
| |
llvm-svn: 123061
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
X = sext x; x >s c ? X : C+1 --> X = sext x; X <s C+1 ? C+1 : X
X = sext x; x <s c ? X : C-1 --> X = sext x; X >s C-1 ? C-1 : X
X = zext x; x >u c ? X : C+1 --> X = zext x; X <u C+1 ? C+1 : X
X = zext x; x <u c ? X : C-1 --> X = zext x; X >u C-1 ? C-1 : X
X = sext x; x >u c ? X : C+1 --> X = sext x; X <u C+1 ? C+1 : X
X = sext x; x <u c ? X : C-1 --> X = sext x; X >u C-1 ? C-1 : X
Instead of calculating this with mixed types promote all to the
larger type. This enables scalar evolution to analyze this
expression. PR8866
llvm-svn: 123034
|
|
|
|
| |
llvm-svn: 123033
|
|
|
|
|
|
| |
sext from i1.
llvm-svn: 122453
|
|
|
|
|
|
|
|
|
|
|
| |
the form
(x & 2^n) ? 2^m+C : C
we can offset both arms by C to get the "(x & 2^n) ? 2^m : 0" form, optimize the
select to a shift and apply the offset afterwards.
llvm-svn: 121609
|
|
|
|
|
|
| |
to catch cases where n != m with a shift.
llvm-svn: 121608
|
|
|
|
| |
llvm-svn: 117510
|
|
|
|
|
|
| |
this one.
llvm-svn: 108530
|
|
|
|
| |
llvm-svn: 108436
|
|
|
|
|
|
|
|
| |
the corresponding or-icmp-and pattern. This has the added benefit of doing
the matching earlier, and thus being less susceptible to being confused by
earlier transforms.
llvm-svn: 108429
|
|
|
|
|
|
| |
This now passes LIT, nighty test, and llvm-gcc bootstrap on my machine.
llvm-svn: 108422
|