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

[Jeffrey A Law <law at redhat dot com>]

On Mon, 2004-06-21 at 11:43, Dave Korn wrote:
>   IOW, it's implicitly assuming that whatever is returned from
> emit_move_insn_1 is a single rtx which is equivalent to the overall effect
> of the set we're currently emitting.
Well, it's certainly the case that we can have a REG_EQUAL note
which describes how a series of insns constructs a value which is
placed into an ultimate destination by the last insn in the sequence.

This happens all the time for REG_LIBCALL/REG_RETVAL sequences and
can also happen for multi-word moves as we've seen with this testcase.

In the case of a multi-word move the right way to describe this is
to have a REG_EQUAL note on the various insns which set components
of the multi-word value.  Those REG_EQUAL notes (of course) refer
to the destination in the specific insn they appear.

At the end of the multi-word move sequence we should have a nop move
of the multi-word value to itself with a REG_EQUAL for the multi-word
value as a whole.

So if we go back to your example, insn 11 and insn 12 ought to have
REG_EQUAL notes which refer to the appropriate sub-components of
(const_double -1).

We should then 
(set (reg:DI 40) (reg:DI 40) (REG_EQUAL (const_double -1)))


That allows us to optimize the components correctly using their
REG_EQUAL notes and to optimize the sequence as a whole using the
REG_EQUAL note on the nop move. 

I'm not sure the best way to fix this, but I'm pretty sure that
if we break a move into components, that each component's REG_EQUAL
note must refer to the destination that's set in each insn and
if we want to refer to the ultimate destination as a whole, then
we need to have a nop move insn with a REG_EQUAL note at the end
of the multi-word move sequence.

jeff