Missed optimizations with indirectbr terminators

[llvmbot]

Bugzilla Link	10377
Version	2.9
OS	Linux
Reporter	LLVM Bugzilla Contributor

Extended Description

Consider this IR fragment produced by opt -O3:

%7: %8 = phi i8 [ blockaddress(@0, %19), %19 ], [ %12, %11 ] %9 = phi i32 [ %20, %19 ], [ 0, %11 ] indirectbr i8 %8, [label %4, label %19]

%19: %20 = add nsw i32 %9, 1 %21 = icmp eq i32 %9, 9999 br i1 %21, label %16, label %7

the br in %19 should be optimized to branch directly to itself rather than going back to %7 (note that the arg %8 to the indirectbr will always be the address of %19 when coming from %19). While this might or might not be so big of a problem per-se, notice how %19 is a loop body that simply adds 1 to the same variable at each iteration. Because the br is still pointing to %7 instead of %18, other passes are not able to recognize that the loop has a constant iteration count and could therefore be replaced entirely by a

%20 = add nsw i32 %9, 10000

[llvmbot]

Here you go. (I know that the unoptimized code is overly verbose and redundant, that will be fixed eventually)

[llvmbot]

Bitcode after O3 on LLVM 2.8+ The conditional br in bb1.b.cgf should not jump to entry.a.cgf but rather to itself. In entry.a.cgf the terminator indirectbr prevents this from happening. Notice that bb1.b.cgf is part of a loop with a known iteration count; the above problems prevents other opts from turning the loop in a single addition.

[llvmbot]

IR before O3 on LLVM 2.8+ Bitcode before opt -O3

[lattner]

Please reopen when you have additional information, such as a testcase, thanks!

[lattner]

Hi Carlo,

Please attach a complete testcase. We've made progress in this area after 2.9, it may already be done on mainline.