This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Delayed branch scheduling pass destroys the CFG data?

Dear all, 

I am trying to embed the control flow graph information into the assembly code 
generated in the final pass of gcc. 

While doing that, I found a very strange situation which the control flow 
graph does not comply with the gcc internal document. In the internal 
document, it is stated that "A CODE_LABEL cannot appear in the instruction 
stream of a basic block" (p155). But in the RTL of a basic block before the 
final pass, there is a CODE_LABEL (171) as following:
----------------start basic block 3 -----------------------------
The rtx in bb: 
(code_label/v 27 93 28 27 "" [0 uses])
(note 28 93 30 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 30 28 171 (set (reg:SI 2 r2 [orig:162 n_lsm.307 ] [162]) 
        (plus:SI (reg:SI 2 r2 [orig:162 n_lsm.307 ] [162])
            (reg:SI 1 r1 [orig:160 ivtmp.313 ] [160]))) 39 {*addsi3_compact} 
(code_label 171 30 31 50 "" [1 uses])
(insn 31 171 33 (set (reg:SI 1 r1 [orig:160 ivtmp.313 ] [160])
        (plus:SI (reg:SI 1 r1 [orig:160 ivtmp.313 ] [160])
            (const_int 1 [0x1]))) 39 {*addsi3_compact} (nil)
(insn 33 31 172 (set (reg:SI 147 t)
        (eq:SI (reg:SI 1 r1 [orig:160 ivtmp.313 ] [160])
            (reg:SI 5 r5 [orig:165 s.2 ] [165]))) 1 {cmpeqsi_t} 
(insn_list:REG_DEP_TRUE 31 (nil))
(insn 172 33 170 (sequence [
            (jump_insn 34 33 30 (set (pc)
                    (if_then_else (eq (reg:SI 147 t)
                            (const_int 0 [0x0]))
                        (label_ref:SI 171)
                        (pc))) 208 {branch_false} (insn_list:REG_DEP_TRUE 33 
                (expr_list:REG_BR_PRED (const_int 12 [0xc])
                    (expr_list:REG_DEAD (reg:SI 147 t)
                        (expr_list:REG_BR_PROB (const_int 9000 [0x2328])
            (insn/s 30 34 170 (set (reg:SI 2 r2 [orig:162 n_lsm.307 ] [162])
                    (plus:SI (reg:SI 2 r2 [orig:162 n_lsm.307 ] [162])
                        (reg:SI 1 r1 [orig:160 ivtmp.313 ] [160]))) 39 
{*addsi3_compact} (nil)
        ]) -1 (nil)

----------------end basic block 3 -----------------------------

You can note that the CODE_LABEL 171 does appear in the basic block. 

Therefore the assemble code generated for this basic block does not comply 
with the definition of a basic block where the basic block should be a linear 
sequence of instructions:

000001d8 <_main_sh_bb3>:
  n = n+i;
 1d8:	32 1c       	add	r1,r2
 1da:	71 01       	add	#1,r1
 1dc:	31 50       	cmp/eq	r5,r1
 1de:	8f fc       	bf.s	1da <_main_sh_bb3+0x2>
 1e0:	32 1c       	add	r1,r2
 1e2:	32 18       	sub	r1,r2

The basic block should be from the address 1da (add #1, r1) to the address 1de 
(bf.s 1da), instead of being from the address 1d8 -> 1e2 as being stored in 
the control flow graph structure. Now if I build the control flow graph from 
the internal data of GCC, I will get a different/wrong result from the result 
I get from the assembly code. 

I though the problem is that the delayed branch scheduling pass changes the 
some instructions for the delayed branch, but it does not change the control 
flow graph data. 

Could you please confirm me if I am correct?
Minh D. Nguyen
Electronic Design Automation
Dept. of Electrical and Computer Eng.
University of Kaiserslautern
67653 Kaiserslautern, Germany
phone: +49 631 205 2609
fax:   +49 631 205 4782

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]