Re: Bug in reload_cse_move2add()

[Joern Rennecke <amylaar at cambridge dot redhat dot com>]

> 
> On Jan  4, 2001, Joern Rennecke <amylaar@redhat.com> wrote:
> 
> >> Good idea!  But what if the earliest register itself is incremented?
> >> (I haven't studied your patch yet)
> 
> > In that case, the optimization would be disabled - because the luid is
> > incremented.  But I think that should hardly ever happen, so little
> > potential performance should be lost.
> 
> How about not modifying the luid of the earliest register, but instead
> just modifying its offset?  The assumption is that the earliest
> register will always have an initial offset of zero, so we can tell by
> how much it has changed since the initial copy.  There already seem to
> be some assumptions about offsets being zero scattered along the code,
> that I believe may have to do with this.

Well, that is because the earliest register is just being itself - it
has an offset of zero against itself.  The offsets are reflecting
differences that the registers have right now, if the luids indicate
that these differences are still valid.

You are bassically proposing to introduce a new meaning of reg_offset for
the base registers - to track any increments since the last non-incrementing
set.  The time of such a most recent non-incrementing set of a base reg
would be noted in the luid.
This is certainly possible, but we'd need to find a new way to distinguish
a register that has been set to a constant, from a register that has some
other value, where we are tracking increments.
E.g., we could continue to use a reg_base_reg value of -1 for the former,
and use -2 for the latter.