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