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