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

Jeffrey A Law law@redhat.com
Thu Apr 21 20:02:00 GMT 2005


On Thu, 2005-04-21 at 15:58 +0200, Richard Guenther wrote:

> I guess the real question is then, why and where do we create this SETs
> to the pseudo (and thus the memory location) in the first place - apart
> from the first initialization of the pseudo, of course - or does that get
> replaced with mem = mem, too?
The sets are created as part of the normal code generation process; ie,
they're initializing the pseudo to its appropriate value.

Note however, that the RHS of the set may be the equivalent memory 
location or another pseudo register which happens to already contain
the right value.  You can have multiple sets and in theory those 
sets could even appear inside PARALLELs.

The equivalences are recorded by update_equiv_regs which keeps track of
what insns create the equivalence -- however, that code only tracks
the equivalence if it is created by an assignment when the LHS is the
pseudo in question and the RHS is MEM.  Later the insns recorded by
update_equiv_regs are removed. 

You can legitimately ask if the requirement that the RHS be a MEM
could be removed, which I would believe would solve this instance
of the problem.

However, I could not convince myself that doing so was actually safe.
Furthermore, as a whole, when I look at this code I see it as *horribly*
fragile, particularly in its handling of SETs occurring inside
PARALLELs.

Ignoring these problematical equivalences is not ideal, but it is
safe.  I'd rather be safe given how fragile this code looks to me.

Jeff



More information about the Gcc-patches mailing list