SH function epilogue scheduling problems

[tm_gccmail@mail.kloo.net]

On Tue, 25 Feb 2003, Joern Rennecke wrote:

> tm_gccmail@mail.kloo.net wrote:
> > 
> > I'm looking at code generated with CVS mainline using -O2 -m4, and it
> > doesn't seem to be scheduling the function epilogue properly.
> > 
> > Here's a sample from advmilitary.i:
> > 

(function epilogue code deleted for brevity)

> > 
> > The instructions marked "here" can and should be moved down several
> > instructions because they will pair with the stack stores, but the
> > scheduler doesn't seem to do anything.
> > 
> > This is the worst case, but it seems to be happening everywhere - none of
> > the function epilogues are properly scheduled.
> > 
> > Is this a known problem?
> 
> Yes.  The scheduler doesn't know about dependencies between stores that might
> go to locations in the stack and irestore from frame pointer / increments of
> the stack pointer.
> As a crude work-around, the sh.c:sh_expand_epilogue functions emits a "blockage"
> instruction before the first stack pointer adjustment.  That "blockage"
> instruction is an unspec_volatile, and hence now the scheduler won't move anything
> past it.
> We need a saner mechanism to avoid moving stores that might go to stack locations
> past the stack pointer adjustments, but allows noon-stores and stores to known
> non-stack locations to move past the adjustments.

It sounds like we need a "memory barrier" or better yet, a "stack
barrier" which blocks movement of stack references?

Actually...as my mind wanders off on a tangent...

It might be useful to have __builtin_memory_barrier for other reasons. It
could be used ensure the sequence of memory accesses for hardware I/O.
We have __builtin_pretch, so why not __builtin_memory_barrier?

Toshi