Duncan Sands eacc31acf5 Since commit 157467, if reassociate isn't actually going to change an expression ... then it doesn't alter the instructions composing it, however it would continue to move the instructions to just before the expression root. Ensure it doesn't move them either, so now it really does nothing if there is nothing to do. That commit also ensured that nsw etc flags weren't cleared if the expression was not being changed. Tweak this a bit so that it doesn't clear flags on the initial part of a computation either if that part didn't change but later bits did. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157518 91177308-0d34-0410-b5e6-96231b3b80d8		2012-05-26 16:42:52 +00:00
..
2002-05-15-AgressiveSubMove.ll
2002-05-15-MissedTree.ll
2002-05-15-SubReassociate2.ll
2002-05-15-SubReassociate.ll
2002-07-09-DominanceProblem.ll
2003-08-12-InfiniteLoop.ll
2005-08-24-Crash.ll
2005-09-01-ArrayOutOfBounds.ll
2006-04-27-ReassociateVector.ll
2011-01-26-UseAfterFree.ll
2012-05-08-UndefLeak.ll	Make the reassociation pass more powerful so that it can handle expressions	2012-05-25 12:03:02 +00:00
basictest.ll
crash.ll
fp-commute.ll	Teach reassociate to commute FMul's and FAdd's in order to canonicalize the order of their operands across instructions. This allows for greater CSE opportunities.	2012-05-07 20:47:23 +00:00
inverses.ll
lit.local.cfg
looptest.ll
mulfactor.ll	Teach the reassociate pass to fold chains of multiplies with repeated	2012-04-26 05:30:30 +00:00
multistep.ll	Calling ReassociateExpression recursively is extremely dangerous since it will	2012-05-08 12:16:05 +00:00
negation.ll
no-op.ll	Since commit 157467, if reassociate isn't actually going to change an expression	2012-05-26 16:42:52 +00:00
optional-flags.ll
otherops.ll
pr12245.ll	The value held in the vector may be RAUW'ed by some of the canonicalization	2012-05-02 09:59:45 +00:00
secondary.ll
shift-factor.ll
shifttest.ll
subtest2.ll
subtest.ll