The attached LLVM code has an uncond branch that isn't removed by branch folding: _main_bb_2E_i9_2E_i_2E_i932_2E_ce: subl $28, %esp movl %esi, 24(%esp) movl %edi, 20(%esp) movl 36(%esp), %esi movl 32(%esp), %eax jmp LBB1_6 #bb.i9.i.i932.ce ... LBB1_6: #bb.i9.i.i932.ce movl (%eax), %edi movl L_outfile$non_lazy_ptr, %eax movl (%eax), %eax The entry block has a single successor, and LBB1_6 has a single predecessor, so branch folding should merge them. -Chris
Created attachment 661 [details] testcase reproduce with: llvm-as < test.ll | llc
By the time branch folding is reached the switch statement has been broken into a binary tree of compares. The target block of the unconditional branch (LBB1_6) thus has two successors, one of which is a fallthrough; the branch folder doesn't move the block up in that case: // If the prior block doesn't fall through into this block, and if this // block doesn't fall through into some other block, see if we can find a // place to move this block where a fall-through will happen. So that's why. The comment doesn't explain why, but obviously hoisting such a block gains no branches in itself. If repeated enough times, however, you eventually get to a fallthrough that returns, and hoisting that will gain a branch (in this case).
Fixed. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070212/044660.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070212/044659.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070212/044661.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070212/044662.html