Re: pa.c clean-up

[Richard Henderson <rth at redhat dot com>]

On Wed, Jan 31, 2001 at 08:01:18PM -0700, Jeffrey A Law wrote:
> When we have a frame pointer our prologue looks something like this:
> 
> 	store return pointer into stack
> 	copy fp, scratch
> 	copy sp, fp
> 	stwm scratch size(sp)	/* store scratch into stack and allocate 
> 				   stack space for new frame */
> 	store other callee saved registers via fp

So what keeps "store other callee" from moving in front of "stwm scratch"?
Or, in general, anything else that uses memory from moving in front of
"stwm scratch"?  Nothing, I'll warrant.

I couldn't make anything bad happen with the simplest of test cases,
because I kept getting a stupid extra copy out of the register allocator
that would throw off the schedule.  But it's simple enough, for the
purposes of illustration, to cheat and use a global register variable.

Consider,

   register int y __asm__("r26");
   void foo()
   {
     const int x = y;
     bar(&x);
   }

I get (-O2 -fno-omit-frame-pointer)

        copy %r3,%r1
        stw %r2,-20(%r30)
        copy %r30,%r3
        stw %r26,8(%r3)
        ldo 8(%r3),%r26
        .CALL ARGW0=GR
        bl bar,%r2
        stwm %r1,128(%r30)

Note that the store of r26 has advanced in front of the stack allocation.
Even with a less contrived example, if you examine the sched2 dumps you'll
see that there is no dependancy between *any* frame pointer store and the
stack allocation.  So you only survive this far by luck.

This is _exactly_ the problem I've encountered before.  You'll run into it
every single time the frame pointer is at the opposite end of the frame as
the stack pointer.  Examine the prologue_allocate_stack pattern in ia64.md
and the pro_epilogue_adjust_stack pattern in i386.md.


r~