aboutsummaryrefslogtreecommitdiff
path: root/lib/Analysis/InstructionSimplify.cpp
AgeCommit message (Collapse)Author
2011-01-29Fix comment.Nick Lewycky
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124544 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-29Move InstCombine's knowledge of fdiv to SimplifyInstruction().Frits van Bommel
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124534 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-28This dyn_cast should be a cast. Pointed out by Frits van Bommel.Duncan Sands
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124497 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-28Thread divisions over selects and phis. This doesn't fire much and has ↵Duncan Sands
basically zero effect on the testsuite (it improves two Ada testcases). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124496 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-28My auto-simplifier noticed that ((X/Y)*Y)/Y occurs several times in SPECDuncan Sands
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124487 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-25According to my auto-simplifier the most common missed simplifications inDuncan Sands
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124183 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-20At -O123 the early-cse pass is run before instcombine has run. According to myDuncan Sands
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123911 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-18For completeness, generalize the (X + Y) - Y -> X transform and add X - (X + ↵Duncan Sands
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123755 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-18Simplify (X<<1)-X into X. According to my auto-simplier this is the most ↵Duncan Sands
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). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123754 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-14Turn X-(X-Y) into Y. According to my auto-simplifier this is the most commonDuncan Sands
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123442 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-14Factorize common code out of the InstructionSimplify shift logic. Add inDuncan Sands
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123441 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-14Move some shift transforms out of instcombine and into InstructionSimplify.Duncan Sands
While there, I noticed that the transform "undef >>a X -> undef" was wrong. For example if X is 2 then the top two bits must be equal, so the result can not be anything. I fixed this in the constant folder as well. Also, I made the transform for "X << undef" stronger: it now folds to undef always, even though X might be zero. This is in accordance with the LangRef, but I must admit that it is fairly aggressive. Also, I added "i32 X << 32 -> undef" following the LangRef and the constant folder, likewise fairly aggressive. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123417 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-13Remove some wrong code which fortunately was never executed (as explained inDuncan Sands
the comment I added): an extern weak global may have a null address. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123373 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-13The most common simplification missed by instsimplify in unoptimized bitcodeDuncan Sands
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-01Revert commit 122654 at the request of Chris, who reckons that instsimplifyDuncan Sands
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-01Fix a README item by having InstructionSimplify do a mild form of valueDuncan Sands
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
2010-12-28Cast away "comparison between signed and unsigned integer" warnings.Benjamin Kramer
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122598 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-22When determining whether the new instruction was already present inDuncan Sands
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-22Add some statistics, good for understanding how much more powerfulDuncan Sands
instcombine is compared to instsimplify. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122397 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-21While I don't think any later transforms can fire, it seems cleaner toDuncan Sands
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-21Fix inverted condition noticed by Frits van Bommel.Duncan Sands
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122331 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-21Pull a few more simplifications out of instcombine (there are stillDuncan Sands
plenty left though!), in particular for multiplication. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122330 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-21Teach InstructionSimplify about distributive laws. These transforms fireDuncan Sands
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-21Move checking of the recursion limit into the various Thread methods.Duncan Sands
No functionality change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122327 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-21Add generic simplification of associative operations, generalizingDuncan Sands
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-20Have SimplifyBinOp dispatch Xor, Add and Sub to the corresponding methodsDuncan Sands
(they had just been forgotten before). Adding Xor causes "main" in the existing testcase 2010-11-01-lshr-mask.ll to be hugely more simplified. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122245 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-15Move Sub simplifications and additional Add simplifications out ofDuncan Sands
instcombine and into InstructionSimplify. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121861 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-15If we detect that the instruction we are simplifying is unreachable, arrange forDuncan Sands
it to be replaced by undef rather than not replaced at all, the idea being that this may reduce the amount of work done by whoever called InstructionSimplify. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121860 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-29Add some dead stores to pacify my least favorite GCC warning: may beChandler Carruth
uninitialized. The warning is terrible, has incorrect source locations, and has a huge false positive rate such as *all* of these. If anyone has a better solution, please let me know. Alternatively, I'll happily add -Wno-uninitialized to the -Werror build mode. Maybe I can even do it *only* when building with GCC instead of Clang. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120281 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-23Expand a little on the description of what InstructionSimplify does.Duncan Sands
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120016 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-22If a GEP index simply advances by multiples of a type of zero size,Duncan Sands
then replace the index with zero. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119974 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-22Move the "gep undef" -> "undef" transform from instcombine toDuncan Sands
InstructionSimplify. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119970 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-21Add a rather pointless InstructionSimplify transform, inspired by recent ↵Duncan Sands
constant folding improvements: if P points to a type of size zero, turn "gep P, N" into "P". More generally, if a gep index type has size zero, instcombine could replace the index with zero, but that is not done here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119942 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-19Remove threading of Xor over selects and phis, with an explanationDuncan Sands
of why such threading is pointless. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119798 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-17Move some those Xor simplifications which don't require creating newDuncan Sands
instructions out of InstCombine and into InstructionSimplify. While there, introduce an m_AllOnes pattern to simplify matching with integers and vectors with all bits equal to one. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119536 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-17Previously SimplifyInstruction could report that an instructionDuncan Sands
simplified to itself (this can only happen in unreachable blocks). Change it to return null instead. Hopefully this will fix some buildbot failures. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119490 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-17Fix a layering violation: hasConstantValue, which is part of the PHINodeDuncan Sands
class, uses DominatorTree which is an analysis. This change moves all of the tricky hasConstantValue logic to SimplifyInstruction, and replaces it with a very simple literal implementation. I already taught users of hasConstantValue that need tricky stuff to use SimplifyInstruction instead. I didn't update InlineFunction because the IR looks like it might be in a funky state at the point it calls hasConstantValue, which makes calling SimplifyInstruction dangerous since it can in theory do a lot of tricky reasoning. This may be a pessimization, for example in the case where all phi node operands are either undef or a fixed constant. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119459 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-16In which I discover the existence of loops. Threading an operationDuncan Sands
over a phi node by applying it to each operand may be wrong if the operation and the phi node are mutually interdependent (the testcase has a simple example of this). So only do this transform if it would be correct to perform the operation in each predecessor of the block containing the phi, i.e. if the other operands all dominate the phi. This should fix the FFMPEG snow.c regression reported by İsmail Dönmez. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119347 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-15Teach InstructionSimplify the trick of skipping incoming phiDuncan Sands
values that are equal to the phi itself. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119161 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-14If dom tree information is available, make it possible to passDuncan Sands
it to get better phi node simplification. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119055 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-14Teach InstructionSimplify about phi nodes. I chose to have it simplyDuncan Sands
offload the work to hasConstantValue rather than do something more complicated (such handling mutually recursive phis) because (1) it is not clear it is worth it; and (2) if it is worth it, maybe such logic would be better placed in hasConstantValue. Adjust some GVN tests which are now cleaned up much further (eg: all phi nodes are removed). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119043 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-14Strip trailing whitespace.Duncan Sands
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119038 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-10Reduce the maximum recursion depth, 5 seems pointlessly too much.Duncan Sands
Probably it should just be 1, but compromise with 3. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118718 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-10Teach InstructionSimplify how to look through PHI nodes. Since PHIDuncan Sands
nodes can be used in loops, this could result in infinite looping if there is no recursion limit, so add such a limit. It is also used for the SelectInst case because in theory there could be an infinite loop there too if the basic block is unreachable. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118694 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-10Simplify binary operations where one operand is a select instruction.Duncan Sands
The simplifications performed here never create new instructions, they only return existing instructions (or a constant), and so are always a win. In theory they should transform (for example) %z = and i32 %x, %y %s = select i1 %cond, i32 %y, i32 %z %r = and i32 %x, %s into %r = and i32 %x, y but in practice they get into a fight with instcombine, and lose. Unfortunately instcombine does a poor job in this case. Nonetheless I'm committing this transform to make it easier to discuss what to do to make peace with instcombine. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118679 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-09Factorize code, no functionality change.Duncan Sands
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118516 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-07Add simplification of floating point comparisons with the resultDuncan Sands
of a select instruction, the same as already exists for integer comparisons. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118379 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-07Fix a README item: when doing a comparison with the resultDuncan Sands
of a select instruction, see if doing the compare with the true and false values of the select gives the same result. If so, that can be used as the value of the comparison. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118378 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-16Revert r114097, adding back in the assertion against replacing an ↵Owen Anderson
Instruction by itself. Now that CorrelatedValuePropagation is more careful not to call SimplifyInstructionsInBlock() on an unreachable block, the issue has been fixed at a higher level. Add a big warning to SimplifyInstructionsInBlock() to hopefully prevent this in the future. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114117 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-16Fix PR8161, in which an unreachable loop causes recursive instruction ↵Owen Anderson
simplification to try to replace an instruction with itself. Add a predicate to the simplifier to prevent this case. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114097 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2025-09-26 02:36:18 +0000