aboutsummaryrefslogtreecommitdiff
path: root/test/Transforms/Reassociate/multistep.ll
AgeCommit message (Collapse)Author
2012-11-13revert r167740Shuxin Yang
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167787 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-12This change is to fix rdar://12571717 which is about assertion in ↵Shuxin Yang
Reassociate pass. The assertion is trigged when the Reassociater tries to transform expression ... + 2 * n * 3 + 2 * m + ... into: ... + 2 * (n*3 + m). In the process of the transformation, a helper routine folds the constant 2*3 into 6, confusing optimizer which is trying the to eliminate the common factor 2, and cannot find 2 any more. Review is pending. But I'd like commit first in order to help those who are waiting for this fix. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167740 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-08Calling ReassociateExpression recursively is extremely dangerous since it willDuncan Sands
replace the operands of expressions with only one use with undef and generate a new expression for the original without using RAUW to update the original. Thus any copies of the original expression held in a vector may end up referring to some bogus value - and using a ValueHandle won't help since there is no RAUW. There is already a mechanism for getting the effect of recursion non-recursively: adding the value to be recursed on to RedoInsts. But it wasn't being used systematically. Have various places where recursion had snuck in at some point use the RedoInsts mechanism instead. Fixes PR12169. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156379 91177308-0d34-0410-b5e6-96231b3b80d8