| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
possible. This goes into instcombine and instsimplify because instsimplify
doesn't need to check hasOneUse since it returns (almost exclusively) constants.
This fixes PR9343 #4 #5 and #8!
llvm-svn: 127064
|
| |
|
|
|
|
| |
true/false or "icmp slt/sge Y, 0".
llvm-svn: 127063
|
| |
|
|
|
|
|
|
|
| |
intersection of the LHS and RHS ConstantRanges and return "false" when
the range is empty.
This simplifies some code and catches some extra cases.
llvm-svn: 126744
|
| |
|
|
|
|
|
| |
also have a zero when numerator = denominator. Reverts parts of r126635 and
r126637.
llvm-svn: 126644
|
| |
|
|
|
|
| |
PR9343.
llvm-svn: 126643
|
| |
|
|
|
|
|
| |
argument), regardless of the divisor. Teach instcombine about this and fix
test7 in PR9343!
llvm-svn: 126635
|
| |
|
|
|
|
|
|
|
| |
function prototype into a call to a varargs prototype. We do
allow the xform if we have a definition, but otherwise we don't
want to risk that we're changing the abi in a subtle way. On
X86-64, for example, varargs require passing stuff in %al.
llvm-svn: 126363
|
| |
|
|
| |
llvm-svn: 126082
|
| |
|
|
|
|
|
|
|
| |
We usually catch this kind of optimization through InstSimplify's distributive
magic, but or doesn't distribute over xor in general.
"A | ~(A | B) -> A | ~B" hits 24 times on gcc.c.
llvm-svn: 126081
|
| |
|
|
|
|
|
| |
the instruction passed in. Make sure to account for this correctly, instead
of looping infinitely.
llvm-svn: 126058
|
| |
|
|
|
|
| |
overflow. These subsume some existing equality transforms, so zap those.
llvm-svn: 125843
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
instcombine xform to exercise this.
Nothing forms exact udivs yet though. This is progress on PR8862
llvm-svn: 124992
|
| |
|
|
|
|
|
| |
reassociation. No testcase, because I wasn't able to create a testcase
which actually demonstrates a problem.
llvm-svn: 124713
|
| |
|
|
|
|
|
| |
(A+B) == A -> B == 0
A == (A+B) -> B == 0
llvm-svn: 124567
|
| |
|
|
| |
llvm-svn: 124535
|
| |
|
|
| |
llvm-svn: 124534
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
benchmarks, and that it can be simplified to X/Y. (In general you can only
simplify (Z*Y)/Y to Z if the multiplication did not overflow; if Z has the
form "X/Y" then this is the case). This patch implements that transform and
moves some Div logic out of instcombine and into InstructionSimplify.
Unfortunately instcombine gets in the way somewhat, since it likes to change
(X/Y)*Y into X-(X rem Y), so I had to teach instcombine about this too.
Finally, thanks to the NSW/NUW flags, sometimes we know directly that "Z*Y"
does not overflow, because the flag says so, so I added that logic too. This
eliminates a bunch of divisions and subtractions in 447.dealII, and has good
effects on some other benchmarks too. It seems to have quite an effect on
tramp3d-v4 but it's hard to say if it's good or bad because inlining decisions
changed, resulting in massive changes all over.
llvm-svn: 124487
|
| |
|
|
| |
llvm-svn: 124469
|
| |
|
|
|
|
|
|
|
|
| |
clang's -Wuninitialized-experimental warning.
While these don't look like real bugs, clang's
-Wuninitialized-experimental analysis is stricter
than GCC's, and these fixes have the benefit
of being general nice cleanups.
llvm-svn: 124073
|
| |
|
|
|
|
|
| |
A == B, and A > B, does not mean we can fold it to true. We still need to
check for A ? B (A unordered B).
llvm-svn: 123993
|
| |
|
|
| |
llvm-svn: 123968
|
| |
|
|
| |
llvm-svn: 123965
|
| |
|
|
|
|
|
| |
a select. A vector select is pairwise on each element so we'd need a new
condition with the right number of elements to select on. Fixes PR8994.
llvm-svn: 123963
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
auto-simplier the transform most missed by early-cse is (zext X) != 0 -> X != 0.
This patch adds this transform and some related logic to InstructionSimplify
and removes some of the logic from instcombine (unfortunately not all because
there are several situations in which instcombine can improve things by making
new instructions, whereas instsimplify is not allowed to do this). At -O2 this
often results in more than 15% more simplifications by early-cse, and results in
hundreds of lines of bitcode being eliminated from the testsuite. I did see some
small negative effects in the testsuite, for example a few additional instructions
in three programs. One program, 483.xalancbmk, got an additional 35 instructions,
which seems to be due to a function getting an additional instruction and then
being inlined all over the place.
llvm-svn: 123911
|