llvm-6502/test/Transforms/SimplifyCFG/2008-05-16-PHIBlockMerge.ll

132 lines
3.4 KiB
LLVM
Raw Normal View History

; RUN: opt < %s -simplifycfg -S > %t
; RUN: not grep "^BB.tomerge" %t
; RUN: grep "^BB.nomerge" %t | count 2
Restucture a part of the SimplifyCFG pass and include a testcase. The SimplifyCFG pass looks at basic blocks that contain only phi nodes, followed by an unconditional branch. In a lot of cases, such a block (BB) can be merged into their successor (Succ). This merging is performed by TryToSimplifyUncondBranchFromEmptyBlock. It does this by taking all phi nodes in the succesor block Succ and expanding them to include the predecessors of BB. Furthermore, any phi nodes in BB are moved to Succ and expanded to include the predecessors of Succ as well. Before attempting this merge, CanPropagatePredecessorsForPHIs checks to see if all phi nodes can be properly merged. All functional changes are made to this function, only comments were updated in TryToSimplifyUncondBranchFromEmptyBlock. In the original code, CanPropagatePredecessorsForPHIs looks quite convoluted and more like stack of checks added to handle different kinds of situations than a comprehensive check. In particular the first check in the function did some value checking for the case that BB and Succ have a common predecessor, while the last check in the function simply rejected all cases where BB and Succ have a common predecessor. The first check was still useful in the case that BB did not contain any phi nodes at all, though, so it was not completely useless. Now, CanPropagatePredecessorsForPHIs is restructured to to look a lot more similar to the code that actually performs the merge. Both functions now look at the same phi nodes in about the same order. Any conflicts (phi nodes with different values for the same source) that could arise from merging or moving phi nodes are detected. If no conflicts are found, the merge can happen. Apart from only restructuring the checks, two main changes in functionality happened. Firstly, the old code rejected blocks with common predecessors in most cases. The new code performs some extra checks so common predecessors can be handled in a lot of cases. Wherever common predecessors still pose problems, the blocks are left untouched. Secondly, the old code rejected the merge when values (phi nodes) from BB were used in any other place than Succ. However, it does not seem that there is any situation that would require this check. Even more, this can be proven. Consider that BB is a block containing of a single phi node "%a" and a branch to Succ. Now, since the definition of %a will dominate all of its uses, BB will dominate all blocks that use %a. Furthermore, since the branch from BB to Succ is unconditional, Succ will also dominate all uses of %a. Now, assume that one predecessor of Succ is not dominated by BB (and thus not dominated by Succ). Since at least one use of %a (but in reality all of them) is reachable from Succ, you could end up at a use of %a without passing through it's definition in BB (by coming from X through Succ). This is a contradiction, meaning that our original assumption is wrong. Thus, all predecessors of Succ must also be dominated by BB (and thus also by Succ). This means that moving the phi node %a from BB to Succ does not pose any problems when the two blocks are merged, and any use checks are not needed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51478 91177308-0d34-0410-b5e6-96231b3b80d8
2008-05-23 09:09:41 +00:00
; ModuleID = '<stdin>'
declare i1 @foo()
declare i1 @bar(i32)
; This function can't be merged
define void @a() {
entry:
br label %BB.nomerge
BB.nomerge: ; preds = %Common, %entry
; This phi has a conflicting value (0) with below phi (2), so blocks
; can't be merged.
%a = phi i32 [ 1, %entry ], [ 0, %Common ] ; <i32> [#uses=1]
br label %Succ
Succ: ; preds = %Common, %BB.nomerge
%b = phi i32 [ %a, %BB.nomerge ], [ 2, %Common ] ; <i32> [#uses=0]
%conde = call i1 @foo( ) ; <i1> [#uses=1]
br i1 %conde, label %Common, label %Exit
Common: ; preds = %Succ
%cond = call i1 @foo( ) ; <i1> [#uses=1]
br i1 %cond, label %BB.nomerge, label %Succ
Exit: ; preds = %Succ
ret void
}
; This function can't be merged
define void @b() {
entry:
br label %BB.nomerge
BB.nomerge: ; preds = %Common, %entry
br label %Succ
Succ: ; preds = %Common, %BB.nomerge
; This phi has confliction values for Common and (through BB) Common,
; blocks can't be merged
%b = phi i32 [ 1, %BB.nomerge ], [ 2, %Common ] ; <i32> [#uses=0]
%conde = call i1 @foo( ) ; <i1> [#uses=1]
br i1 %conde, label %Common, label %Exit
Common: ; preds = %Succ
%cond = call i1 @foo( ) ; <i1> [#uses=1]
br i1 %cond, label %BB.nomerge, label %Succ
Exit: ; preds = %Succ
ret void
}
; This function can be merged
define void @c() {
entry:
br label %BB.tomerge
BB.tomerge: ; preds = %Common, %entry
br label %Succ
Succ: ; preds = %Common, %BB.tomerge, %Pre-Exit
; This phi has identical values for Common and (through BB) Common,
; blocks can't be merged
%b = phi i32 [ 1, %BB.tomerge ], [ 1, %Common ], [ 2, %Pre-Exit ]
%conde = call i1 @foo( ) ; <i1> [#uses=1]
br i1 %conde, label %Common, label %Pre-Exit
Common: ; preds = %Succ
%cond = call i1 @foo( ) ; <i1> [#uses=1]
br i1 %cond, label %BB.tomerge, label %Succ
Pre-Exit: ; preds = %Succ
; This adds a backedge, so the %b phi node gets a third branch and is
; not completely trivial
%cond2 = call i1 @foo( ) ; <i1> [#uses=1]
br i1 %cond2, label %Succ, label %Exit
Exit: ; preds = %Pre-Exit
ret void
}
; This function can be merged
define void @d() {
entry:
br label %BB.tomerge
BB.tomerge: ; preds = %Common, %entry
; This phi has a matching value (0) with below phi (0), so blocks
; can be merged.
%a = phi i32 [ 1, %entry ], [ 0, %Common ] ; <i32> [#uses=1]
br label %Succ
Succ: ; preds = %Common, %BB.tomerge
%b = phi i32 [ %a, %BB.tomerge ], [ 0, %Common ] ; <i32> [#uses=0]
%conde = call i1 @foo( ) ; <i1> [#uses=1]
br i1 %conde, label %Common, label %Exit
Common: ; preds = %Succ
%cond = call i1 @foo( ) ; <i1> [#uses=1]
br i1 %cond, label %BB.tomerge, label %Succ
Exit: ; preds = %Succ
ret void
}
; This function can be merged
define void @e() {
entry:
br label %BB.tomerge
BB.tomerge: ; preds = %Use, %entry
; This phi is used somewhere else than Succ, but this should not prevent
; merging this block
%a = phi i32 [ 1, %entry ], [ 0, %Use ] ; <i32> [#uses=1]
br label %Succ
Succ: ; preds = %BB.tomerge
%conde = call i1 @foo( ) ; <i1> [#uses=1]
br i1 %conde, label %Use, label %Exit
Use: ; preds = %Succ
%cond = call i1 @bar( i32 %a ) ; <i1> [#uses=1]
br i1 %cond, label %BB.tomerge, label %Exit
Exit: ; preds = %Use, %Succ
ret void
}