Re: [PATCH] Avoid scheduling fp or sp related loads across sp restore on ppc64 (PR target/44199)

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, May 25, 2010 at 02:54:49PM -0400, David Edelsohn wrote:
> On Fri, May 21, 2010 at 4:36 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> 
>        PR target/44199
>        * config/rs6000/rs6000.c (rs6000_emit_epilogue): If cfun->calls_alloca
>        or total_size is larger than red zone size for non-V4 ABI, emit a
>        stack_tie resp. frame_tie insn before stack pointer restore.
>        * config/rs6000/rs6000.md (frame_tie): New insn.
> 
> What is the status of this patch?  It looks okay in principle.  I did

It has been tested on both trunk and 4.4 branch.

> not see an answer to Alan's question about the constraint for operand
> 1.

Apparently I've missed Alan's mail, sorry about that.
frame_tie is used only when frame_pointer_needed, so most of the automatic
variables would be frame pointer based.  Stack based addresses are
just argument pushes (but those would be followed by call or dead store
eliminated) or alloca/VLA references (but I believe they would use some
pointer register instead of being directly sp related).

Initially I was using the stack_tie pattern with just frame pointer based
address instead of stack pointer based one, unfortunately that
lead to the addi r1, r31, XXX instruction being moved across that insn.
I think it could work even if it just used r1 register in the pattern.

Another alternative is using (mem:BLK (scratch)) in the stack_tie pattern
in these two cases and not introduce frame_tie insn.

	Jakub