PR rtl-optimization/15248 -- semi-latent reload bug

[Roger Sayle]

On Thu, 21 Apr 2005, Jeffrey A Law wrote:
> If it weren't for the problems we're having in our *implementation*,
> yes, absolutely.
>
> ...
> What you're missing is that when the pseudo doesn't get a hard register,
> we must eliminate all assignments to the pseudo as any assignment to the
> pseudo will generate a write to a read-only memory location.
>
> What makes that particular problem non-trivial to solve is PARALLELs and
> the bookkeeping problems in the reg_equiv_XXX arrays if we have a pseudo
> equivalenced to a read-only memory location which was assigned a hard
> reg which we later spilled.

Thanks for the explanations.  Clearly my understanding is along the
right tracks.

In this case, wouldn't a better solution be to allow the equivalencing
of the pseudo to the read-only memory, but instead simply not to emit
the store that attempts to write to read-only memory.  We know that the
location already contains the correct value, so somewhere in reload,
where ever we spill this pseudo, we just need a check something like:
!(MEM_P(x) && !MEM_READONLY_P(x)) probably before calling emit_insn.

I appreciate your comment that the implementation might be slightly
more involved in order to deal with PARALLELs, CLOBBERs and the like,
but I'd be interested in knowing where the erroneous code is.

There's nothing wrong with your solution, except that we'll use a
stack slot for the spill when we don't have to.  Perserving the
REG_EQUIV both avoids this extra spill slot, and improves performance
by not having to write to memory.  Once this fix is in place, we
could even tweak reload to prefer to spill registers equivalenced
to constants and read-only memory.

Roger
--