From bddfb2f96b889e641f6ca7e2cbacaeba38a58c09 Mon Sep 17 00:00:00 2001 From: Duncan Sands Date: Fri, 25 May 2012 12:03:02 +0000 Subject: 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. llvm-svn: 157467 --- llvm/test/Transforms/Reassociate/2012-05-08-UndefLeak.ll | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'llvm/test/Transforms') diff --git a/llvm/test/Transforms/Reassociate/2012-05-08-UndefLeak.ll b/llvm/test/Transforms/Reassociate/2012-05-08-UndefLeak.ll index 80193615693..1e522e61601 100644 --- a/llvm/test/Transforms/Reassociate/2012-05-08-UndefLeak.ll +++ b/llvm/test/Transforms/Reassociate/2012-05-08-UndefLeak.ll @@ -1,8 +1,12 @@ ; RUN: opt < %s -reassociate -S | FileCheck %s ; PR12169 +; PR12764 define i64 @f(i64 %x0) { -; CHECK-NOT: undef +; CHECK: @f +; CHECK-NEXT: mul i64 %x0, 208 +; CHECK-NEXT: add i64 %{{.*}}, 1617 +; CHECK-NEXT: ret i64 %t0 = add i64 %x0, 1 %t1 = add i64 %x0, 2 %t2 = add i64 %x0, 3 -- cgit v1.2.3