basic_block_head[]/basic_block_tail[] questions

Toshiyasu Morita tm@netcom.com
Sat Aug 15 04:24:00 GMT 1998


I'm seeing some strange problems with reload and I think it may have 
something to do with basic_block_head[] and basic_block_tail[]...

Specifically, the current implementation of basic_block_head[] and 
basic_block_tail[] seem to point at actual insns. This seems bad
because reload calls emit_insn_before() and emit_insn_after(), and these 
functions seem unaware of the existence of the basic_block_head/tail arrays.

Consider: if reload generates a spill for the first insn of a 
basic block, it seems to insert the insns into the basic block outside 
the one intended, or even outside the outermost basic block, like this:

;; Insn is not within a basic block
(insn 930 4 931 (set (reg:SI 0 r0)
        (const_int 188)) -1 (nil)
    (nil))

;; Insn is not within a basic block
(insn 931 930 6 (set (reg:SI 0 r0)
        (plus:SI (reg:SI 0 r0)
            (reg:SI 14 r14))) 18 {addsi3} (nil)
    (expr_list:REG_EQUIV (plus:SI (reg:SI 14 r14)
            (const_int 188))
        (nil)))

;; Start of basic block 0, registers live: 4 [r4] 14 [r14] 15 [r15] 48 [fpscr]
(insn:HI 6 931 880 (set (mem/u:SI (plus:SI (reg:SI 0 r0)
                (const_int 4)))
        (reg:SI 4 r4)) 121 {movsi_ie} (nil)
    (expr_list:REG_DEAD (reg:SI 4 r4)
        (nil)))

If this analysis is correct, and this problem hasn't been addressed already, 
then it may be prudent to insert INSN_DELETED notes at the head and tail 
of a basic block at which basic_block_head/basic_block_tail may point so  
reload can always properly insert insns before/after the first/last insn 
of a basic block?

Toshi



More information about the Gcc-bugs mailing list