Re: pa.c clean-up

[Jeffrey A Law <law at redhat dot com>]

  In message <Pine.LNX.4.21.0102011234360.19209-100000@front.linuxcare.com.au>y
ou write:
  > On Wed, 31 Jan 2001, Jeffrey A Law wrote:
  > 
  > >   In message <Pine.LNX.4.21.0101242053430.29059-100000@front.linuxcare.co
  > m.au>y
  > > ou write:
  > >   > Besides some tidying of code, this patch fixes a couple of bugs
  > > This should be split into multiple patches.
  > 
  > Darn, I was hoping this was a small enough chunk.  Yet to come is some
  > 5k lines of diffs in gcc/config/pa...
  > 
  > Some is moving header files around so as to cleanly add in hppa{,64}-linux
  > support, but there's other goodies like DWARF2 support for pa, and 64 bit
  > millicode support contributed by HP (ie. cross compilers without stealing
  > milli.a from an HP box)
Most of this will likely have to wait until after the branch.

  > > That would indicate a problem elsewhere since there should have been
  > > a dependency between the insn which adjusts the stack pointer and any
  > > stores in the prologue which use the stack pointer in their address.
  > 
  > You have a similar blockage in the epilogue.  Hmm, based on rth's comment
  > about frame pointer access into the stack, I don't need all the
  > blockages.  I'll rip out the non-frame pointer ones.
Bad debugging memories....  When we have a frame pointer epilogues look
something like

	load via fp
	load via fp
	load via fp
	copy fp,sp

From a scheduling standpoint there's nothing which would prevent the copy
from moving up since it doesn't modify fp and thus we don't have any kind
data dependency to prevent movement.

Contrast that to the prologue where we do have dependencies:

        stw %r2,-20(%r30)  Must happen before stwm, but there's an obvious
			   dependency on the stwm as stwm updates the stack
			   pointer (r30)
        copy %r3,%r1	   Must happen before next copy because next copy
			   modifies r3
        copy %r30,%r3	   Must happen before stwm because stwm modifies
			   r30
        stwm %r1,64(%r30)

 	stores via %r3 (aka fp)  Hmmm, OK.  I don't see how we're going
				 to get a dependency between these stores
				 and the stwm.  Sigh.  Yes, we probably do
				 want a blockage after we allocate the
				 stack in a function with a frame pointer.


jeff