6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-11-10 17:07:06 +00:00
Code Issues Projects Releases Wiki Activity
9c210dabda
llvm-6502/test/Transforms/Reassociate/2012-05-08-UndefLeak.ll

86 lines
2.1 KiB
LLVM
Raw Normal View History

Calling ReassociateExpression recursively is extremely dangerous since it will 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
2012-05-08 12:16:05 +00:00
; RUN: opt < %s -reassociate -S | FileCheck %s
; PR12169
Make the reassociation pass more powerful so that it can handle expressions with arbitrary topologies (previously it would give up when hitting a diamond in the use graph for example). The testcase from PR12764 is now reduced from a pile of additions to the optimal 1617*%x0+208. In doing this I changed the previous strategy of dropping all uses for expression leaves to one of dropping all but one use. This works out more neatly (but required a bunch of tweaks) and is also safer: some recently fixed bugs during recursive linearization were because the linearization code thinks it completely owns a node if it has no uses outside the expression it is linearizing. But if the node was also in another expression that had been linearized (and thus all uses of the node from that expression dropped) then the conclusion that it is completely owned by the expression currently being linearized is wrong. Keeping one use from within each linearized expression avoids this kind of mistake. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157467 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-25 12:03:02 +00:00
; PR12764
Stop reassociate from looking through expressions of arbitrary complexity. This is a temporary measure until my fix for PR13021 is ready. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160778 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-26 09:26:40 +00:00
; XFAIL: *
; Transform disabled until PR13021 is fixed.
Calling ReassociateExpression recursively is extremely dangerous since it will 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
2012-05-08 12:16:05 +00:00
define i64 @f(i64 %x0) {
Make the reassociation pass more powerful so that it can handle expressions with arbitrary topologies (previously it would give up when hitting a diamond in the use graph for example). The testcase from PR12764 is now reduced from a pile of additions to the optimal 1617*%x0+208. In doing this I changed the previous strategy of dropping all uses for expression leaves to one of dropping all but one use. This works out more neatly (but required a bunch of tweaks) and is also safer: some recently fixed bugs during recursive linearization were because the linearization code thinks it completely owns a node if it has no uses outside the expression it is linearizing. But if the node was also in another expression that had been linearized (and thus all uses of the node from that expression dropped) then the conclusion that it is completely owned by the expression currently being linearized is wrong. Keeping one use from within each linearized expression avoids this kind of mistake. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157467 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-25 12:03:02 +00:00
; CHECK: @f
; CHECK-NEXT: mul i64 %x0, 208
; CHECK-NEXT: add i64 %{{.*}}, 1617
; CHECK-NEXT: ret i64
Calling ReassociateExpression recursively is extremely dangerous since it will 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
2012-05-08 12:16:05 +00:00
%t0 = add i64 %x0, 1
%t1 = add i64 %x0, 2
%t2 = add i64 %x0, 3
%t3 = add i64 %x0, 4
%t4 = add i64 %x0, 5
%t5 = add i64 %x0, 6
%t6 = add i64 %x0, 7
%t7 = add i64 %x0, 8
%t8 = add i64 %x0, 9
%t9 = add i64 %x0, 10
%t10 = add i64 %x0, 11
%t11 = add i64 %x0, 12
%t12 = add i64 %x0, 13
%t13 = add i64 %x0, 14
%t14 = add i64 %x0, 15
%t15 = add i64 %x0, 16
%t16 = add i64 %x0, 17
%t17 = add i64 %x0, 18
%t18 = add i64 %t17, %t0
%t19 = add i64 %t18, %t1
%t20 = add i64 %t19, %t2
%t21 = add i64 %t20, %t3
%t22 = add i64 %t21, %t4
%t23 = add i64 %t22, %t5
%t24 = add i64 %t23, %t6
%t25 = add i64 %t24, %t7
%t26 = add i64 %t25, %t8
%t27 = add i64 %t26, %t9
%t28 = add i64 %t27, %t10
%t29 = add i64 %t28, %t11
%t30 = add i64 %t29, %t12
%t31 = add i64 %t30, %t13
%t32 = add i64 %t31, %t14
%t33 = add i64 %t32, %t15
%t34 = add i64 %t33, %t16
%t35 = add i64 %t34, %x0
%t36 = add i64 %t0, %t1
%t37 = add i64 %t36, %t2
%t38 = add i64 %t37, %t3
%t39 = add i64 %t38, %t4
%t40 = add i64 %t39, %t5
%t41 = add i64 %t40, %t6
%t42 = add i64 %t41, %t7
%t43 = add i64 %t42, %t8
%t44 = add i64 %t43, %t9
%t45 = add i64 %t44, %t10
%t46 = add i64 %t45, %t11
%t47 = add i64 %t46, %t12
%t48 = add i64 %t47, %t13
%t49 = add i64 %t48, %t14
%t50 = add i64 %t49, %t15
%t51 = add i64 %t50, %t16
%t52 = add i64 %t51, %t17
%t53 = add i64 %t52, %t18
%t54 = add i64 %t53, %t19
%t55 = add i64 %t54, %t20
%t56 = add i64 %t55, %t21
%t57 = add i64 %t56, %t22
%t58 = add i64 %t57, %t23
%t59 = add i64 %t58, %t24
%t60 = add i64 %t59, %t25
%t61 = add i64 %t60, %t26
%t62 = add i64 %t61, %t27
%t63 = add i64 %t62, %t28
%t64 = add i64 %t63, %t29
%t65 = add i64 %t64, %t30
%t66 = add i64 %t65, %t31
%t67 = add i64 %t66, %t32
%t68 = add i64 %t67, %t33
%t69 = add i64 %t68, %t34
%t70 = add i64 %t69, %t35
%t71 = add i64 %t70, %x0
ret i64 %t71
}
Reference in New Issue Copy Permalink