| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch can identify
ABS(X) ==> (X >s 0) ? X : -X and (X >s -1) ? X : -X
ABS(X) ==> (X <s 0) ? -X : X and (X <s 1) ? -X : X
NABS(X) ==> (X >s 0) ? -X : X and (X >s -1) ? -X : X
NABS(X) ==> (X <s 0) ? X : -X and (X <s 1) ? X : -X
and can transform
ABS(ABS(X)) -> ABS(X)
NABS(NABS(X)) -> NABS(X)
Differential Revision: http://reviews.llvm.org/D3658
llvm-svn: 210312
|
|
|
|
|
|
|
|
|
|
|
|
| |
if ((x & C) == 0) x |= C becomes x |= C
if ((x & C) != 0) x ^= C becomes x &= ~C
if ((x & C) == 0) x ^= C becomes x |= C
if ((x & C) != 0) x &= ~C becomes x &= ~C
if ((x & C) == 0) x &= ~C becomes nothing
Differential Revision: http://reviews.llvm.org/D3777
llvm-svn: 210006
|
|
|
|
|
|
|
|
|
|
|
| |
This removes TODO added in r208849 [http://reviews.llvm.org/D3629]
MIN(MIN(A, 97), 23) -> MIN(A, 23)
MAX(MAX(A, 23), 97) -> MAX(A, 97)
Differential Revision: http://reviews.llvm.org/D3785
llvm-svn: 209110
|
|
|
|
|
|
| |
sanitizer-x86_64-linux-bootstrap/builds/3399
llvm-svn: 208852
|
|
|
|
|
|
|
|
|
| |
MIN(MIN(A, 23), 97) -> MIN(A, 23)
MAX(MAX(A, 97), 23) -> MAX(A, 97)
Differential Revision: http://reviews.llvm.org/D3629
llvm-svn: 208849
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if ((x & C) == 0) x |= C becomes x |= C
if ((x & C) != 0) x ^= C becomes x &= ~C
if ((x & C) == 0) x ^= C becomes x |= C
if ((x & C) != 0) x &= ~C becomes x &= ~C
if ((x & C) == 0) x &= ~C becomes nothing
Z3 Verifications code for above transform
http://rise4fun.com/Z3/Pmsh
Differential Revision: http://reviews.llvm.org/D3717
llvm-svn: 208848
|
|
|
|
| |
llvm-svn: 207196
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
definition below all of the header #include lines, lib/Transforms/...
edition.
This one is tricky for two reasons. We again have a couple of passes
that define something else before the includes as well. I've sunk their
name macros with the DEBUG_TYPE.
Also, InstCombine contains headers that need DEBUG_TYPE, so now those
headers #define and #undef DEBUG_TYPE around their code, leaving them
well formed modular headers. Fixing these headers was a large motivation
for all of these changes, as "leaky" macros of this form are hard on the
modules implementation.
llvm-svn: 206844
|
|
|
|
|
|
|
|
|
|
|
| |
header files and into the cpp files.
These files will require more touches as the header files actually use
DEBUG(). Eventually, I'll have to introduce a matched #define and #undef
of DEBUG_TYPE for the header files, but that comes as step N of many to
clean all of this up.
llvm-svn: 206777
|
|
|
|
|
|
| |
obviously is coupled to the IR.
llvm-svn: 202818
|
|
|
|
|
|
|
|
|
| |
I am really sorry for the noise, but the current state where some parts of the
code use TD (from the old name: TargetData) and other parts use DL makes it
hard to write a patch that changes where those variables come from and how
they are passed along.
llvm-svn: 201827
|
|
|
|
|
|
| |
instructions. All found by inspection (aka grep).
llvm-svn: 199528
|
|
|
|
|
|
|
|
|
|
| |
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
|