Commit Graph

109 Commits

Author SHA1 Message Date
Duncan Sands
6dc91253ab 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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123372 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-13 08:56:29 +00:00
Duncan Sands
124708d9b4 Revert commit 122654 at the request of Chris, who reckons that instsimplify
is the wrong hammer for this nail, and is probably right.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122661 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-01 20:08:02 +00:00
Duncan Sands
7cf85e74e3 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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122654 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-01 16:12:09 +00:00
Duncan Sands
1cd05bb605 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. 


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122414 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-22 17:15:25 +00:00
Duncan Sands
025c98bdbd Add an additional InstructionSimplify factorization test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122333 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-21 15:12:22 +00:00
Duncan Sands
07f30fbd73 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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122332 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-21 15:03:43 +00:00
Duncan Sands
9bd2c2e63c Fix typo in comment, spotted by Deewiant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122329 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-21 13:39:20 +00:00
Duncan Sands
3421d90853 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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122328 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-21 13:32:22 +00:00
Duncan Sands
566edb04b8 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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122326 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-21 08:49:00 +00:00