Bug in reload_cse_move2add()

Joern Rennecke amylaar@cambridge.redhat.com
Thu Jan 4 13:11:00 GMT 2001


> 
> On Jan  4, 2001, Joern Rennecke <amylaar@redhat.com> wrote:
> 
> > 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.
> 
> Yep.  My understanding is that the luids indicate the point at which
> the register was initially set.  The offset may vary from that point
> on, in case the register is incremented or decremented (or do I
> misremember?)

Yes, but that was actually the reason for the bug.  I was thinking of a
false dichotomy of base registers and registers that are based on them.

> > 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.
> 
> It's not new.  It's just pretending that the original earliest base
> register is still available, under a different name, and that any
> registers that use it as a base are actually based on that other
> register.

I don't see it this way, but let's just agree to disagree on that point...
if this use is new or not is of no consequence for the proposed solutions.

> Why not reg_base_reg[regno] == regno?  It doesn't seem to me it would
> be that different from current usage, but I'd have to check.

Yes, that's another possibility.  It would avoid making it harder to test
for a register set to a constant, but make it more awkward to test for
a register where we don't want to look at the base register instead of
the register itself.

I suspect that overall, my proposal would cause less code increase.


More information about the Gcc-patches mailing list