| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is part of a futile attempt to not "break" bizzaro
code like this:
l1:
printf("l1: %p\n", &&l1);
++x;
if( x < 3 ) goto l1;
Previously we'd fold &&l1 to 1, which is fine per our semantics
but not helpful to the user.
llvm-svn: 125827
|
|
|
|
|
|
| |
common operations through a phi.
llvm-svn: 125790
|
|
|
|
| |
llvm-svn: 125787
|
|
|
|
|
|
| |
result inbounds if all of the inputs are inbounds.
llvm-svn: 125785
|
|
|
|
| |
llvm-svn: 125774
|
|
|
|
|
|
|
|
|
| |
for some
variations (some of these were already present so I unified the code). Spotted by my
auto-simplifier as occurring a lot.
llvm-svn: 125734
|
|
|
|
| |
llvm-svn: 125711
|
|
|
|
|
|
| |
it swaps the LHS/RHS of a single binop.
llvm-svn: 125700
|
|
|
|
| |
llvm-svn: 125563
|
|
|
|
|
|
|
| |
The pattern "A&(A^B) -> A & ~B" recreated itself because ~B is
actually a xor -1.
llvm-svn: 125557
|
|
|
|
| |
llvm-svn: 125547
|
|
|
|
| |
llvm-svn: 125546
|
|
|
|
| |
llvm-svn: 125537
|
|
|
|
|
|
| |
that is modified inside loop.
llvm-svn: 125529
|
|
|
|
|
|
| |
builders unhappy.
llvm-svn: 125504
|
|
|
|
|
|
| |
idiom. Change various clients to simplify their code.
llvm-svn: 125487
|
|
|
|
| |
llvm-svn: 125464
|
|
|
|
|
|
| |
We were previously simplifying divisions, but not right shifts!
llvm-svn: 125454
|
|
|
|
| |
llvm-svn: 125451
|
|
|
|
|
|
| |
putchar transforms, their return values are not compatible.
llvm-svn: 125442
|
|
|
|
| |
llvm-svn: 125411
|
|
|
|
|
|
|
|
| |
unsigned overflow (e.g. due to a negative array index), but
the scales on array size multiplications are known to not
sign wrap.
llvm-svn: 125409
|
|
|
|
|
|
|
| |
a loop when unswitching it. It only does this in the complex case, because
everything should be fine already in the simple case.
llvm-svn: 125369
|
|
|
|
| |
llvm-svn: 125368
|
|
|
|
|
|
| |
iv-users twice.
llvm-svn: 125318
|
|
|
|
| |
llvm-svn: 125317
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gep to explicit addressing, we know that none of the intermediate
computation overflows.
This could use review: it seems that the shifts certainly wouldn't
overflow, but could the intermediate adds overflow if there is a
negative index?
Previously the testcase would instcombine to:
define i1 @test(i64 %i) {
%p1.idx.mask = and i64 %i, 4611686018427387903
%cmp = icmp eq i64 %p1.idx.mask, 1000
ret i1 %cmp
}
now we get:
define i1 @test(i64 %i) {
%cmp = icmp eq i64 %i, 1000
ret i1 %cmp
}
llvm-svn: 125271
|
|
|
|
|
|
|
|
|
|
|
| |
exact/nsw/nuw shifts and have instcombine infer them when it can prove
that the relevant properties are true for a given shift without them.
Also, a variety of refactoring to use the new patternmatch logic thrown
in for good luck. I believe that this takes care of a bunch of related
code quality issues attached to PR8862.
llvm-svn: 125267
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
optimizations to be much more aggressive in the face of
exact/nsw/nuw div and shifts. For example, these (which
are the same except the first is 'exact' sdiv:
define i1 @sdiv_icmp4_exact(i64 %X) nounwind {
%A = sdiv exact i64 %X, -5 ; X/-5 == 0 --> x == 0
%B = icmp eq i64 %A, 0
ret i1 %B
}
define i1 @sdiv_icmp4(i64 %X) nounwind {
%A = sdiv i64 %X, -5 ; X/-5 == 0 --> x == 0
%B = icmp eq i64 %A, 0
ret i1 %B
}
compile down to:
define i1 @sdiv_icmp4_exact(i64 %X) nounwind {
%1 = icmp eq i64 %X, 0
ret i1 %1
}
define i1 @sdiv_icmp4(i64 %X) nounwind {
%X.off = add i64 %X, 4
%1 = icmp ult i64 %X.off, 9
ret i1 %1
}
This happens when you do something like:
(ptr1-ptr2) == 42
where the pointers are pointers to non-unit types.
llvm-svn: 125266
|
|
|
|
|
|
| |
conversions". :)
llvm-svn: 125265
|
|
|
|
|
|
|
|
|
|
| |
and generally tidying things up. Only very trivial functionality changes
like now doing (-1 - A) -> (~A) for vectors too.
InstCombineAddSub.cpp | 296 +++++++++++++++++++++-----------------------------
1 file changed, 126 insertions(+), 170 deletions(-)
llvm-svn: 125264
|
|
|
|
|
|
|
| |
are shifting out since they do require them to be zeros. Similarly
for NUW/NSW bits of shl
llvm-svn: 125263
|
|
|
|
| |
llvm-svn: 125257
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Natural Loop Information
Loop Pass Manager
Canonicalize natural loops
Scalar Evolution Analysis
Loop Pass Manager
Induction Variable Users
Canonicalize natural loops
Induction Variable Users
Loop Strength Reduction
into this:
Scalar Evolution Analysis
Loop Pass Manager
Canonicalize natural loops
Induction Variable Users
Loop Strength Reduction
This fixes <rdar://problem/8869639>. I also filed PR9184 on doing this sort of
thing automatically, but it seems easier to just change the ordering of the
passes if this is the only case.
llvm-svn: 125254
|
|
|
|
|
|
| |
improve interfaces to instsimplify to take this info.
llvm-svn: 125196
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
versions of creation functions. Eventually, the "insertion point" versions
of these should just be removed, we do have IRBuilder afterall.
Do a massive rewrite of much of pattern match. It is now shorter and less
redundant and has several other widgets I will be using in other patches.
Among other changes, m_Div is renamed to m_IDiv (since it only matches
integer divides) and m_Shift is gone (it used to match all binops!!) and
we now have m_LogicalShift for the one client to use.
Enhance IRBuilder to have "isExact" arguments to things like CreateUDiv
and reduce redundancy within IRbuilder by having these methods chain to
each other more instead of duplicating code.
llvm-svn: 125194
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
could end up removing a different function than we intended because it was
functionally equivalent, then end up with a comparison of a function against
itself in the next round of comparisons (the one in the function set and the
one on the deferred list). To fix this, I introduce a choice in the form of
comparison for ComparableFunctions, either normal or "pointer only" used to
find exact Function*'s in lookups.
Also add some debugging statements.
llvm-svn: 125180
|
|
|
|
|
|
|
|
| |
the active loop. This is generally desirable, and it avoids trouble
in situations such as the testcase in PR9123, though the failure
mode depends on use-list order, so it is infeasible to test.
llvm-svn: 125065
|
|
|
|
|
|
|
|
| |
switch. If we used only one icmp, don't turn it into a switch.
Also prevent the switch-to-icmp transform from creating identity adds, noticed by Marius Wachtler.
llvm-svn: 125056
|
|
|
|
|
|
|
|
| |
instcombine xform to exercise this.
Nothing forms exact udivs yet though. This is progress on PR8862
llvm-svn: 124992
|
|
|
|
| |
llvm-svn: 124977
|
|
|
|
|
|
| |
now, and this wasn't comparing some of their relevant bits anyhow.
llvm-svn: 124976
|
|
|
|
|
|
|
|
| |
are not sorted into sub+icmp.
This transforms another 1000 switches in gcc.c.
llvm-svn: 124826
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the job of the later optzn passes easier, allowing the vast amount of
icmp transforms to chew on it.
We transform 840 switches in gcc.c, leading to a 16k byte shrink of the resulting
binary on i386-linux.
The testcase from README.txt now compiles into
decl %edi
cmpl $3, %edi
sbbl %eax, %eax
andl $1, %eax
ret
llvm-svn: 124724
|
|
|
|
|
|
|
|
| |
that might have changed been affected by a merge elsewhere will have been
removed from the function set, and it isn't needed for performance because we
call grow() ahead of time to prevent reallocations.
llvm-svn: 124717
|
|
|
|
|
|
|
| |
reassociation. No testcase, because I wasn't able to create a testcase
which actually demonstrates a problem.
llvm-svn: 124713
|
|
|
|
| |
llvm-svn: 124712
|
|
|
|
|
|
|
| |
(A+B) == A -> B == 0
A == (A+B) -> B == 0
llvm-svn: 124567
|
|
|
|
|
|
| |
The DEBUG() call at line 606 demands to see raw_ostream's definition. I have no idea why this seems to only break MSVC.
llvm-svn: 124545
|
|
|
|
| |
llvm-svn: 124535
|