http://llvm.org/bugs/show_bug.cgi?id=10072
Bill Wendling <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |[email protected] Resolution| |INVALID --- Comment #1 from Bill Wendling <[email protected]> 2011-06-03 15:19:45 CDT --- In the particular example you gave, we get this after the first few optimization passes: [Irk:llvm] opt < mod.ll -S -mem2reg -globalopt -ipsccp -deadargelim -instcombine ; ModuleID = '<stdin>' @xblkx.bbs = internal unnamed_addr constant [9 x i8*] [i8* blockaddress(@xfuncx, %xblkx.begin), i8* blockaddress(@xfuncx, %xblkx.begin3), i8* blockaddress(@xfuncx, %xblkx.begin4), i8* blockaddress(@xfuncx, %xblkx.begin5), i8* blockaddress(@xfuncx, %xblkx.begin6), i8* blockaddress(@xfuncx, %xblkx.begin7), i8* blockaddress(@xfuncx, %xblkx.begin8), i8* blockaddress(@xfuncx, %xblkx.begin9), i8* blockaddress(@xfuncx, %xblkx.end)] define void @xfuncx() { escape-string.top: %xval202x = call i32 @xfunc5x() br label %xlab5x xlab8x: ; preds = %xlab5x %xvaluex = call i32 @xselectorx() %xblkx.x = getelementptr [9 x i8*]* @xblkx.bbs, i32 0, i32 %xvaluex %xblkx.load = load i8** %xblkx.x indirectbr i8* %xblkx.load, [label %xblkx.begin, label %xblkx.begin3, label %xblkx.begin4, label %xblkx.begin5, label %xblkx.begin6, label %xblkx.begin7, label %xblkx.begin8, label %xblkx.begin9, label %xblkx.end] xblkx.begin: ; preds = %xlab8x br label %xblkx.end xblkx.begin3: ; preds = %xlab8x br label %xblkx.end xblkx.begin4: ; preds = %xlab8x br label %xblkx.end xblkx.begin5: ; preds = %xlab8x br label %xblkx.end xblkx.begin6: ; preds = %xlab8x br label %xblkx.end xblkx.begin7: ; preds = %xlab8x br label %xblkx.end xblkx.begin8: ; preds = %xlab8x br label %xblkx.end xblkx.begin9: ; preds = %xlab8x br label %xblkx.end xblkx.end: ; preds = %xblkx.begin9, %xblkx.begin8, %xblkx.begin7, %xblkx.begin6, %xblkx.begin5, %xblkx.begin4, %xblkx.begin3, %xblkx.begin, %xlab8x %yes.0 = phi i1 [ false, %xblkx.begin ], [ true, %xlab8x ], [ false, %xblkx.begin9 ], [ false, %xblkx.begin8 ], [ false, %xblkx.begin7 ], [ false, %xblkx.begin6 ], [ false, %xblkx.begin5 ], [ false, %xblkx.begin4 ], [ false, %xblkx.begin3 ] br i1 %yes.0, label %v2j, label %xlab17x v2j: ; preds = %xblkx.end br label %xlab4x xlab17x: ; preds = %xblkx.end br label %xlab4x xlab4x: ; preds = %xlab17x, %v2j %incr19 = add i32 %xval704x.0, 1 br label %xlab5x xlab5x: ; preds = %xlab4x, %escape-string.top %xval704x.0 = phi i32 [ 0, %escape-string.top ], [ %incr19, %xlab4x ] %xval10x = icmp ult i32 %xval704x.0, %xval202x br i1 %xval10x, label %xlab8x, label %xlab9x xlab9x: ; preds = %xlab5x ret void } The "simplifycfg" pass comes along and realizes that the result of all indirectbr branches wind up in the same place, and so eliminates it: [Irk:llvm] opt < mod.ll -S -mem2reg -globalopt -ipsccp -deadargelim -instcombine -simplifycfg ; ModuleID = '<stdin>' @xblkx.bbs = internal unnamed_addr constant [9 x i8*] [i8* blockaddress(@xfuncx, %xlab4x), i8* blockaddress(@xfuncx, %xlab4x), i8* blockaddress(@xfuncx, %xlab4x), i8* blockaddress(@xfuncx, %xlab4x), i8* blockaddress(@xfuncx, %xlab4x), i8* blockaddress(@xfuncx, %xlab4x), i8* blockaddress(@xfuncx, %xlab4x), i8* blockaddress(@xfuncx, %xlab4x), i8* blockaddress(@xfuncx, %xlab4x)] define void @xfuncx() { escape-string.top: %xval202x = call i32 @xfunc5x() br label %xlab5x xlab8x: ; preds = %xlab5x %xvaluex = call i32 @xselectorx() br label %xlab4x xlab4x: ; preds = %xlab8x %incr19 = add i32 %xval704x.0, 1 br label %xlab5x xlab5x: ; preds = %xlab4x, %escape-string.top %xval704x.0 = phi i32 [ 0, %escape-string.top ], [ %incr19, %xlab4x ] %xval10x = icmp ult i32 %xval704x.0, %xval202x br i1 %xval10x, label %xlab8x, label %xlab9x xlab9x: ; preds = %xlab5x ret void } Do you have another testcase which would show the failure? I.e., where all of the branches of the indirectbr don't execute the same code? If so, please reopen this bug. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ LLVMbugs mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
