[PATCH] Better Function Prologue and Epilogue for sh

[Joern Rennecke]

"Nitin Gupta--SSW, Noida" wrote:
> Putting stack adjust there is necessary since that should be the last
> instruction in this optimized case. We are restoring registers from offsets
> of Stack Pointer. SP adjustment cannot move anywhere else.

You can exclude the last register to be restored from this optimization,
thus giving a smaller stack adjustment.  Scheduling that last restore in
the delay slot is better than any pairing with an EX/MT instruction could be.
This will also allow the stack adjustment to be paired with the preceding
restore.

> To avoid changing the home of return address and also to save on the extra
> insn used for handling PR register, I will modify the patch that will have
> code generated in prologue as
> 
>       (barrier here)
>       add       #60,r15
>       mov.l     r14, (56,r15)
>       mov       r15,r14
>       (barrier here)
>       mov.l      r13,@(52,r15)
>       mov.l      r12,@(48,r15)
>       mov.l      r11,@(44,r15)
>       mov.l      r10,@(40,r15)
>       mov.l      r9,@(36,r15)
>       mov.l      r8,@(32,r15)
>         mov.l        pr, r1
>         mov.l        r1,@(28,r15)
> 
> This will follow the ABI and save PR after saving all the registers and thus
> no need to have sh_set_return_address and initial_elimination_offset. PR
> will be at the same location on stack as it will be without the
> optimization. Will it be correct in such a scenario?

Yes, although suboptimal.  The ABI doesn't really say where the registers are
saved, you just have to find them when required, and also properly describe
where they are in the debug and unwinding information.

> > But first, you should test if having a blockage instruction
> > is really the
> > problem, or if the problem is that it's a universal blockage
> > instruction.
> > What we really want is a stack memory blockage.  Try to make
> > an insn pattern
> > that sets a BLKmode object to an unspec value; the memory
> > reference for the
> > destination should be in alias set 0, and could be something
> > that describes
> > and object that is addressed off the frame or stack pointer
> > and as large as
> > the stack frame (basically, that *is* the stack frame).
> 
> The problem with the blockage instruction is that in the epilogue we have
> many instruction in the blockage area. Actually we are reducing the number
> of instructions in the blockage area and thus allow the scheduler to move
> some non LS group insns to move into the LS group insns generated by
> epilogue. By this mechanism we are getting better scheduling of instructions
> as pointed in http://gcc.gnu.org/ml/gcc-bugs/2003-02/msg01290.html

I think you didn't quite understand me.  If we use a more specific blockage
instruction, MT and EX group instructions can pass through this blockage.
So changing the prologue / epilogue is only beneficial if we need to move some
memory instructions from outside the prologue/epilogue into them in order to
get better schedulking.
	
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658