Bogus REG_EQUIV note generation [was RE: Deep CSE bug!]

[Jeffrey A Law]

On Wed, 2004-06-23 at 11:57, Dave Korn wrote:

>   It just occurs to me to wonder exactly when to emit it.  Just after the
> loop that decomposes the subwords is this bit of code
> 
>       /* Show the output dies here.  This is necessary for SUBREGs
> 	 of pseudos since we cannot track their lifetimes correctly;
> 	 hard regs shouldn't appear here except as return values.
> 	 We never want to emit such a clobber after reload.  */
>       if (x != y
> 	  && ! (reload_in_progress || reload_completed)
> 	  && need_clobber != 0)
> 	emit_insn (gen_rtx_CLOBBER (VOIDmode, x));
I believe these clobbers are for life analysis only.  Regardless
I would expect that if you emit the nop move that the clobber would
no longer be necessary.


> 
> >  You might have a peek at
> > emit_no_conflict_block.  In fact, I'm not sure why we're not using
> > emit_no_conflict_block since it's whole purpose is to do a series
> > of operations on a multi-word object one word at a time, add the
> > necessary notes, etc etc.
> 
>   Mmmm, so I see.  Mind you it only emits the REG_EQUAL note on the last
> insn, which is the situation that was causing the problem in the first
> place: having a const_double REG_EQUAL on an insn that only set one single
> subword part. 
It should be emitting the REG_EQUAL note on the nop move, which is
where a REG_EQUAL note for the entire quantity belongs.  Yes, I know
it doesn't emit REG_EQUAL notes for the sub-component moves.  That's
something we'd probably need to add.

>   Maybe an effective approach would be to replace the decomposition loop in
> emit_move_insn_1 with a call to emit_no_conflict_block and get
> emit_no_conflict_block to emit decomposed REG_EQUAL notes and a nop move
Well, emit_no_conflict_block needs a list of insns, so you'd want
to build a sequence of insns with emit_move_insn, then use 
emit_no_conflict_block to emit the clobber before the sequence and
the nop-move with a REG_EQUAL note after the sequence.

Jeff