1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-31 16:02:52 +01:00
Commit Graph

48 Commits

Author SHA1 Message Date
Benjamin Kramer
ec933b857e InstSimplify: Don't try to replace an extractvalue/insertvalue pair with the original value if types don't match.
Fixes clang selfhost.

llvm-svn: 139120
2011-09-05 18:16:19 +00:00
Duncan Sands
a74d10bb60 Add some simple insertvalue simplifications, for the purpose of cleaning
up do-nothing exception handling code produced by dragonegg.

llvm-svn: 139113
2011-09-05 06:52:48 +00:00
Nick Lewycky
7c36f4590e Remove bogus test: for all possible inputs of %X, the 'sub nsw' is guaranteed
to perform a signed wrap. Don't rely on any particular handling of that case.

llvm-svn: 135471
2011-07-19 08:22:57 +00:00
Dan Gohman
ba1afd789e Improve constant folding of undef for cmp and select operators.
llvm-svn: 134223
2011-07-01 01:03:43 +00:00
Dan Gohman
b4be67ddb0 Improve constant folding of undef for binary operators.
llvm-svn: 134221
2011-07-01 00:42:17 +00:00
Duncan Sands
77695f14dc The comparision "max(x,y)==x" is equivalent to "x>=y". Since the max is
often expressed as "x >= y ? x : y", there is a good chance we can extract
the existing "x >= y" from it and use that as a replacement for "max(x,y)==x".

llvm-svn: 131049
2011-05-07 16:56:49 +00:00
Duncan Sands
586612a764 Add variations on: max(x,y) >= min(x,z) folds to true. This isn't that common,
but according to my super-optimizer there are only two missed simplifications
of -instsimplify kind when compiling bzip2, and this is one of them.  It amuses
me to have bzip2 be perfectly optimized as far as instsimplify goes!

llvm-svn: 130840
2011-05-04 16:05:05 +00:00
Duncan Sands
7497273b12 Implement some basic simplifications involving min/max, for example
max(a,b) >= a -> true.  According to my super-optimizer, these are
by far the most common simplifications (of the -instsimplify kind)
that occur in the testsuite and aren't caught by -std-compile-opts.

llvm-svn: 130780
2011-05-03 19:53:10 +00:00
Duncan Sands
750a066af1 Move some rem transforms out of instcombine and into instsimplify.
This automagically provides a transform noticed by my super-optimizer
as occurring quite often: "rem x, (select cond, x, 1)" -> 0.

llvm-svn: 130694
2011-05-02 16:27:02 +00:00
Benjamin Kramer
5986a24bae Teach ComputeMaskedBits about sub nsw.
llvm-svn: 127548
2011-03-12 17:18:11 +00:00
Nick Lewycky
cf0e3e88df Teach ComputeMaskedBits about nsw on add. I don't think there's anything we can
do with nuw here, but sub and mul should be given similar treatment.
Fixes PR9343 #15!

llvm-svn: 127463
2011-03-11 09:00:19 +00:00
Benjamin Kramer
8313cf1cf4 Fix mistyped CHECK lines.
llvm-svn: 127366
2011-03-09 22:07:31 +00:00
Nick Lewycky
485af203fc Add another micro-optimization. Apologies for the lack of refactoring, but I
gave up when I realized I couldn't come up with a good name for what the
refactored function would be, to describe what it does.

This is PR9343 test12, which is test3 with arguments reordered. Whoops!

llvm-svn: 127318
2011-03-09 06:26:03 +00:00
Nick Lewycky
a2cb87f86d Thread comparisons over udiv/sdiv/ashr/lshr exact and lshr nuw/nsw whenever
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
2011-03-05 05:19:11 +00:00
Nick Lewycky
75a3dd996d Revert broken srem logic from r126991.
llvm-svn: 127021
2011-03-04 19:26:08 +00:00
Nick Lewycky
3bc3a84ba8 Fold "icmp pred (srem X, Y), Y" like we do for urem. Handle signed comparisons
in the urem case, though not the other way around. This is enough to get #3 from
PR9343!

llvm-svn: 126991
2011-03-04 10:06:52 +00:00
Nick Lewycky
a5f309e983 Teach instruction simplify to use constant ranges to solve problems of the form
"icmp pred %X, CI" and a number of examples where "%X = binop %Y, CI2".

Some of these cases (div and rem) used to make it through opt -O2, but the
others are probably now making code elsewhere redundant (probably instcombine).

llvm-svn: 126988
2011-03-04 07:00:57 +00:00
Nick Lewycky
e9d448e997 Optimize "icmp pred (urem X, Y), Y" --> true/false depending on pred. There's
more work to do here, "icmp ult (urem X, 10), 11" doesn't optimize away yet.
Fixes example 3 from PR9343!

llvm-svn: 126741
2011-03-01 08:15:50 +00:00
Duncan Sands
c5e791fdd9 Teach instsimplify that X+Y>=X+Z is the same as Y>=Z if neither side overflows,
plus some variations of this.  According to my auto-simplifier this occurs a lot
but usually in combination with max/min idioms.  Because max/min aren't handled
yet this unfortunately doesn't have much effect in the testsuite.

llvm-svn: 125462
2011-02-13 17:15:40 +00:00
Chris Lattner
02088f3ab8 Teach instsimplify some tricks about exact/nuw/nsw shifts.
improve interfaces to instsimplify to take this info.

llvm-svn: 125196
2011-02-09 17:15:04 +00:00
Chris Lattner
1c1b342a62 teach instsimplify to transform (X / Y) * Y to X
when the div is an exact udiv.

llvm-svn: 124994
2011-02-06 22:05:31 +00:00
Chris Lattner
8d427ed03c rename test.
llvm-svn: 124993
2011-02-06 21:59:10 +00:00
Duncan Sands
fc33df78c1 Improve threading of comparisons over select instructions (spotted by my
auto-simplifier).  This has a big impact on Ada code, but not much else.
Unfortunately the impact is mostly negative!  This is due to PR9004 (aka
SCCP failing to resolve conditional branch conditions in the destination
blocks of the branch), in which simple correlated expressions are not
resolved but complicated ones are, so simplifying has a bad effect!

llvm-svn: 124788
2011-02-03 09:37:39 +00:00
Duncan Sands
7eecb72021 Reenable the transform "(X*Y)/Y->X" when the multiplication is known not to
overflow (nsw flag), which was disabled because it breaks 254.gap.  I have
informed the GAP authors of the mistake in their code, and arranged for the
testsuite to use -fwrapv when compiling this benchmark.

llvm-svn: 124746
2011-02-02 20:52:00 +00:00
Duncan Sands
06e82c76ee Have m_One also match constant vectors for which every element is 1.
llvm-svn: 124655
2011-02-01 08:39:12 +00:00
Duncan Sands
987c8bc759 Commit 124487 broke 254.gap. See if disabling the part that might be triggered
by PR9088 fixes things.

llvm-svn: 124561
2011-01-30 18:24:20 +00:00
Duncan Sands
ac01c21937 Transform (X/Y)*Y into X if the division is exact. Instcombine already knows how
to do this and more, but would only do it if X/Y had only one use.  Spotted as the
most common missed simplification in SPEC by my auto-simplifier, now that it knows
about nuw/nsw/exact flags.  This removes a bunch of multiplications from 447.dealII
and 483.xalancbmk.  It also removes a lot from tramp3d-v4, which results in much
more inlining.

llvm-svn: 124560
2011-01-30 18:03:50 +00:00
Frits van Bommel
92dc04df67 Move InstCombine's knowledge of fdiv to SimplifyInstruction().
llvm-svn: 124534
2011-01-29 15:26:31 +00:00
Duncan Sands
0587f785bf Fix typo: should have been testing that X was odd, not V.
llvm-svn: 124533
2011-01-29 13:27:00 +00:00
Duncan Sands
1a18d8df96 My auto-simplifier noticed that ((X/Y)*Y)/Y occurs several times in SPEC
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
2011-01-28 16:51:11 +00:00
Duncan Sands
017a3d76f7 In which I discover that zero+zero is zero, d'oh!
llvm-svn: 124188
2011-01-25 15:14:15 +00:00
Duncan Sands
76eef3df7e Turn off this test - the corresponding instsimplify logic has been
disabled.

llvm-svn: 124185
2011-01-25 12:31:43 +00:00
Duncan Sands
92b081bd42 According to my auto-simplifier the most common missed simplifications in
optimized code are:
  (non-negative number)+(power-of-two) != 0 -> true
and
  (x | 1) != 0 -> true
Instcombine knows about the second one of course, but only does it if X|1
has only one use.  These fire thousands of times in the testsuite.

llvm-svn: 124183
2011-01-25 09:38:29 +00:00
Duncan Sands
1faa8712c9 At -O123 the early-cse pass is run before instcombine has run. According to my
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
2011-01-20 13:21:55 +00:00
Duncan Sands
732cb58b61 For completeness, generalize the (X + Y) - Y -> X transform and add X - (X + 1) -> -1.
These were not recommended by my auto-simplifier since they don't fire often enough.
However they do fire from time to time, for example they remove one subtraction from
the final bitcode for 483.xalancbmk.

llvm-svn: 123755
2011-01-18 11:50:19 +00:00
Duncan Sands
2abe6f500f Simplify (X<<1)-X into X. According to my auto-simplier this is the most common missed
simplification in fully optimized code.  It occurs sporadically in the testsuite, and
many times in 403.gcc: the final bitcode has 131 fewer subtractions after this change.
The reason that the multiplies are not eliminated is the same reason that instcombine
did not catch this: they are used by other instructions (instcombine catches this with
a more general transform which in general is only profitable if the operands have only
one use).

llvm-svn: 123754
2011-01-18 09:24:58 +00:00
Duncan Sands
dc51b0ee48 Turn X-(X-Y) into Y. According to my auto-simplifier this is the most common
simplification present in fully optimized code (I think instcombine fails to
transform some of these when "X-Y" has more than one use).  Fires here and
there all over the test-suite, for example it eliminates 8 subtractions in
the final IR for 445.gobmk, 2 subs in 447.dealII, 2 in paq8p etc.

llvm-svn: 123442
2011-01-14 15:26:10 +00:00
Duncan Sands
4757061c47 Factorize common code out of the InstructionSimplify shift logic. Add in
threading of shifts over selects and phis while there.  This fires here and
there in the testsuite, to not much effect.  For example when compiling spirit
it fires 5 times, during early-cse, resulting in 6 more cse simplifications,
and 3 more terminators being folded by jump threading, but the final bitcode
doesn't change in any interesting way: other optimizations would have caught
the opportunity anyway, only later.

llvm-svn: 123441
2011-01-14 14:44:12 +00:00
Duncan Sands
01be7e406d Rename this test.
llvm-svn: 123440
2011-01-14 14:16:33 +00:00
Duncan Sands
36b007d63b The most common simplification missed by instsimplify in unoptimized bitcode
is "X != 0 -> X" when X is a boolean.  This occurs a lot because of the way
llvm-gcc converts gcc's conditional expressions.  Add this, and a few other
similar transforms for completeness.

llvm-svn: 123372
2011-01-13 08:56:29 +00:00
Duncan Sands
aaddf57af9 Revert commit 122654 at the request of Chris, who reckons that instsimplify
is the wrong hammer for this nail, and is probably right.

llvm-svn: 122661
2011-01-01 20:08:02 +00:00
Duncan Sands
ec8b2b4cc5 Fix a README item by having InstructionSimplify do a mild form of value
numbering, in which it considers (for example) "%a = add i32 %x, %y" and
"%b = add i32 %x, %y" to be equal because the operands are equal and the
result of the instructions only depends on the values of the operands.
This has almost no effect (it removes 4 instructions from gcc-as-one-file),
and perhaps slows down compilation: I measured a 0.4% slowdown on the large
gcc-as-one-file testcase, but it wasn't statistically significant.

llvm-svn: 122654
2011-01-01 16:12:09 +00:00
Duncan Sands
68d969c2f5 When determining whether the new instruction was already present in
the original instruction, half the cases were missed (making it not
wrong but suboptimal).  Also correct a typo (A <-> B) in the second
chunk. 

llvm-svn: 122414
2010-12-22 17:15:25 +00:00
Duncan Sands
658dd68e10 Add an additional InstructionSimplify factorization test.
llvm-svn: 122333
2010-12-21 15:12:22 +00:00
Duncan Sands
b4497c7e0f While I don't think any later transforms can fire, it seems cleaner to
not assume this (for example in case more transforms get added below
it).  Suggested by Frits van Bommel.

llvm-svn: 122332
2010-12-21 15:03:43 +00:00
Duncan Sands
3ceeaf218e Fix typo in comment, spotted by Deewiant.
llvm-svn: 122329
2010-12-21 13:39:20 +00:00
Duncan Sands
0bd25425b6 Teach InstructionSimplify about distributive laws. These transforms fire
quite often, but don't make much difference in practice presumably because
instcombine also knows them and more.

llvm-svn: 122328
2010-12-21 13:32:22 +00:00
Duncan Sands
5880f299da Add generic simplification of associative operations, generalizing
a couple of existing transforms.  This fires surprisingly often, for
example when compiling gcc "(X+(-1))+1->X" fires quite a lot as well
as various "and" simplifications (usually with a phi node operand).
Most of the time this doesn't make a real difference since the same
thing would have been done elsewhere anyway, eg: by instcombine, but
there are a few places where this results in simplifications that we
were not doing before.

llvm-svn: 122326
2010-12-21 08:49:00 +00:00