Re: Bootstrap failure on sh-linux target (PR 13567)

[Jim Wilson <wilson at specifixinc dot com>]

kaz Kojima wrote:
> (insn 29 27 31 1 (set (subreg:SI (reg:DI 166 [ sz ]) 4)
>         (const_int 0 [0x0])) 123 {movsi_ie} (nil)
>     (expr_list:REG_NO_CONFLICT (reg/v:SI 163 [ sz ])
>         (nil)))
> (insn 31 29 33 1 (set (reg:DI 169 [ sz ])
>         (reg:DI 166 [ sz ])) 136 {*movdi_i} (nil)
>     (insn_list:REG_RETVAL 30 (expr_list:REG_EQUAL (const_int 0 [0x0])
>             (nil))))

This is a no-conflict block.  It is generated by emit_no_conflict_block 
in optabs.c.  If you look at the comments before that function, it tells 
you what a no-conflict block looks like.  One of the things it says is 
that the last instruction is a no-op move that moves the target to 
itself.  So this no-conflict block is already broken here, probably by 
cse.  I suspect we need to teach cse not to modify the dest of the last 
instruction of a no-conflict block.  Or else, if it does modify the dest 
of the last insn, it must also change all other uses of the old dest to 
use the new dest.  However, since cse only looks at one insn at a time, 
this probably means that we can't make the replacement at all.

There is another question here of why we have a no-conflict block in the 
first place.  This is used when the target can't handle a multi-register 
move whose source and dest do not conflict (and thus can be allocated to 
the same register pair).  But gcse is simplifying the no-conflict block 
into a DImode move, so it was never necessary here in the first place. 
Perhaps we can avoid the problem by not generating no-conflict blocks 
when we don't need them.  Then gcse won't be able to optimize them away 
like this, and perhaps the problem can't appear anymore.  We probably 
still need to fix cse though to be safe, so it isn't clear if this 
approach is helpful.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com