[LLVMbugs] [Bug 1069] NEW: Incorrect Post-Dominance Frontier Calculation
bugzilla-daemon at cs.uiuc.edu
bugzilla-daemon at cs.uiuc.edu
Tue Dec 26 13:42:33 PST 2006
http://llvm.org/bugs/show_bug.cgi?id=1069
Summary: Incorrect Post-Dominance Frontier Calculation
Product: libraries
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Core LLVM classes
AssignedTo: unassignedbugs at nondot.org
ReportedBy: lefever at crhc.uiuc.edu
To the best of my knowledge, I have come across a bug in the post-dominance
frontier computation in LLVM. In particular, LLVM computes the following
post-dominance frontier for the function at the end of this message:
Basic Block Post-Dominance-Frontier
----------- -----------------------
entry -
bb -
cond_next8 cond_next
cond_next12 cond_next
cond_next -
bb21 cond_next8, cond_next12
cond_true27 cond_next8, cond_next12
pop.exit cond_next8, cond_next12
cond_true.i cond_true27
return ??? return was not even listed in LLVM's PDF.
However, I believe the post-dominance frontier should be computed as such:
Basic Block Post-Dominance-Frontier
----------- -----------------------
entry -
cond_next entry
cond_next8 cond_next
cond_next12 cond_next8
bb21 cond_next8, cond_next12
cond_true27 bb21
cond_true.i cond_true27
pop.exit bb21
bb cond_next, cond_next12
return entry, bb21
Below is the function.
-----------------------------------------
void %load_array(int %var_name) {
entry:
%tmp = call sbyte %check_stack( int 1 ) ; <sbyte> [#uses=1]
%tmp = seteq sbyte %tmp, 0 ; <bool> [#uses=1]
br bool %tmp, label %return, label %cond_next
cond_next: ; preds = %entry
%tmp = load %struct.bc_var** %ex_stack ; <%struct.bc_var*>
[#uses=1]
%tmp = getelementptr %struct.bc_var* %tmp, int 0, uint 0
; <%struct.bc_struct**> [#uses=1]
%tmp = load %struct.bc_struct** %tmp ; <%struct.bc_struct*>
[#uses=2]
%tmp = call int %bc_num2long( %struct.bc_struct* %tmp ) ; <int>
[#uses=4]
%tmp2 = setlt int %tmp, 0 ; <bool> [#uses=1]
%tmp6 = setgt int %tmp, 65535 ; <bool> [#uses=1]
%bothcond = or bool %tmp2, %tmp6 ; <bool> [#uses=1]
br bool %bothcond, label %bb, label %cond_next8
cond_next8: ; preds = %cond_next
%tmp10 = seteq int %tmp, 0 ; <bool> [#uses=1]
br bool %tmp10, label %cond_next12, label %bb21
cond_next12: ; preds = %cond_next8
%tmp16 = call sbyte %bc_is_zero( %struct.bc_struct* %tmp )
; <sbyte> [#uses=1]
%tmp17 = seteq sbyte %tmp16, 0 ; <bool> [#uses=1]
br bool %tmp17, label %bb, label %bb21
bb: ; preds = %cond_next12, %cond_next
%tmp = load sbyte*** %a_names ; <sbyte**> [#uses=1]
%tmp19 = getelementptr sbyte** %tmp, int %var_name ;
<sbyte**> [#uses=1]
%tmp = load sbyte** %tmp19 ; <sbyte*> [#uses=1]
call void (sbyte*, ...)* %rt_error( sbyte* getelementptr ([34 x sbyte]*
%str, int 0, uint 0), sbyte* %tmp )
ret void
bb21: ; preds = %cond_next12, %cond_next8
%tmp24 = call %struct.bc_struct** %get_array_num( int %var_name, int
%tmp ) ; <%struct.bc_struct**> [#uses=2]
%tmp26 = seteq %struct.bc_struct** %tmp24, null ; <bool> [#uses=1]
br bool %tmp26, label %return, label %cond_true27
cond_true27: ; preds = %bb21
%tmp.i = load %struct.bc_var** %ex_stack ;
<%struct.bc_var*> [#uses=4]
%tmp.i = seteq %struct.bc_var* %tmp.i, null ; <bool> [#uses=1]
br bool %tmp.i, label %pop.exit, label %cond_true.i
cond_true.i: ; preds = %cond_true27
%tmp.i = getelementptr %struct.bc_var* %tmp.i, int 0, uint 1
; <%struct.bc_var**> [#uses=1]
%tmp3.i = load %struct.bc_var** %tmp.i ; <%struct.bc_var*>
[#uses=1]
store %struct.bc_var* %tmp3.i, %struct.bc_var** %ex_stack
%tmp.i = getelementptr %struct.bc_var* %tmp.i, int 0, uint 0
; <%struct.bc_struct**> [#uses=1]
call void %bc_free_num( %struct.bc_struct** %tmp.i )
%tmp5.i = bitcast %struct.bc_var* %tmp.i to sbyte* ;
<sbyte*> [#uses=1]
call void %free( sbyte* %tmp5.i )
br label %pop.exit
pop.exit: ; preds = %cond_true.i, %cond_true27
%tmp29 = load %struct.bc_struct** %tmp24 ;
<%struct.bc_struct*> [#uses=1]
call void %push_copy( %struct.bc_struct* %tmp29 )
ret void
return: ; preds = %bb21, %entry
ret void
}
-----------------------------------------
Regards,
Ryan
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
More information about the llvm-bugs
mailing list