egcs-2.92.02 19980905 (m68k-next-nextstep3): Address of hoisted load clobbered

Mark Mitchell
Wed Sep 9 20:50:00 GMT 1998

>>>>> "Richard" == Richard Henderson <> writes:

    Richard> On Tue, Sep 08, 1998 at 07:20:25PM +0200, Toon Moene
    Richard> wrote:
    >> An excerpt from the assmebly output, around the unrolled inner
    >> loop:
    >> fmoved a4@,fp1 <-- Load hoisted movel d4,d0 movel sp@(60),a4
    >> <-- Bleeeccchhhh mulsl a4@,d0 ...  fmoved fp1,a4@ <-- Store
    >> sunk
    >> which, of course, results in a Segmentation Violation.

    Richard> I'm not sure who is at fault here, and request guidance
    Richard> from the gods of reload.  The problem is shared rtl.  It
    Richard> may be solved with the following patch

    Richard> 	* loop.c (load_mems): Copy rtx for output mem.

That's right; reload does stomp all over MEMs, and they should not be
shared.  I forgot about this.  The bit to hoist the loads has the same
problem, actually.

Thank you for finding this; you've fixing up my slop a lot lately.  I
take solace in the fact that Toon is probably happer to have his loops
go faster, even if we suffer some crashes in the short term.

Would you like to fix the load-hoist as well, while you're there, or
would you like me to submit one patch for both problems?

    Richard> But I'm unclear on the rules of shared rtl.  I would have
    Richard> thought that would have had to handle something like this
    Richard> already.

The manual says:

   * Only one `mem' object is normally created for each static variable
     or stack slot, so these objects are frequently shared in all the
     places they appear.  However, separate but equal objects for these
     variables are occasionally made.

Not that that fully clears up the matter...

Mark Mitchell
Mark Mitchell Consulting

More information about the Gcc mailing list