bogon reload.c patch

Jeffrey A Law law@cygnus.com
Mon Sep 21 21:26:00 GMT 1998


Just in case your're wondering...  Here's the series of events that
lead to the problem on the mn103.  It's missing a little context, but
you might be able to get a handle on what's going on :-)

Anyways, I've reverted the problem reload.c patch.  We'll look for a
better solution.

--

What happens is that during the first pass through reload, we see that
the initializing insn for reg 154 has a REG_EQUIV note (mem (reg 3))
so we set reg_equiv_address to (reg:SI d3).  We then start rewriting all
insns that use (reg 154) to use (mem (reg 3)) instead.  The initializing
instruction is modified.  The insn that uses the value is not.  So now
we have a minor inconsistency, since one place uses (reg 154) and one
place uses (mem (reg 3)).  This is only a minor problem though, because
at the end of reload (reg 154) will be modified to refer to (mem (reg 3)).
This is done via a reload created by find_reloads_address.

At the end of the first pass through reload, reg 3 is spilled.

During the second pass through reload, we see that reg 154 now is a mem
of a pseudo, so we allocate a stack slot for it and invalidate the
reg_equiv_address info that we have already used.  Now we have a major problem,
because the two instructions refering to (reg 154) now point to two different
addresses.  The init insn points to (mem (pseudo)) and the using insn points
to (mem (stack slot)).  This inconsistency confuses reload, causing us to
get incorrect code at the end.




More information about the Gcc-bugs mailing list