basic_block_head[]/basic_block_tail[] questions

basic_block_head[]/basic_block_tail[] questions

[Toshiyasu Morita]

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

Re: basic_block_head[]/basic_block_tail[] questions

[Jeffrey A Law]

  In message < 199808151124.EAA24081@netcom8.netcom.com >you write:
  > 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:
It's a problem, but not a serious one.  Nothing bad should happen as
far as I know.

Of course, by not having those insns in basic blocks they are not
being scheduled, which is a performance issue.

Feel free to submit code to try and fix this (or even subcases).
jeff

Re: basic_block_head[]/basic_block_tail[] questions

[Toshiyasu Morita]

> 
> 
>   In message < 199808151124.EAA24081@netcom8.netcom.com >you write:
>   > 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:
> It's a problem, but not a serious one.  Nothing bad should happen as
> far as I know.

Actually, I found this anomoly while investigating PR 16819, in which a 
C++ constructor fails to return 'this', and I suspect this anomoly is the
root reason for this bug.

Toshi