[LLVMdev] register scavenger

[Arnold Schwaighofer]

On Sun, Nov 11, 2012 at 2:29 PM, Reed Kotler <rkotler at mips.com> wrote:
> I ran into another issue with register scavenger.
> I'm wondering if my version of  saveScavengerRegister uses say T0 and T1
> (mips32 registers) for emergency spill slots will work. The usual inline
> code which goes to the emergency slot only
> allows for one emergency spill slot. But my routine would only fail if
> more than two emergency slots were needed but maybe other things would be
> messed up.

Currently, PEI::scavengeFrameVirtualRegs is not set up to handle 2
concurrently live vregs (easy to fix, change the code in PEI to use an
array of - instead of the two variables - VirtReg, ScratchReg). Also,
the RegisterScavenger does not support scavenging for 2 live regs.
This one would be a little more involved to fix I think. You would
have to change the logic in RegisterScavenger involving ScavengedReg
to also use an array, then in your TRI->saveScavengerRegister
implementation you would have to check the liveness of the first spill
register when you scavenge, and if it is live use the second. You
might be able to use RegisterScavengers internal liveness state for
this. I think it tracks registers that are not allocatable and not
reserved - I am not sure about this though.

> I can work around the problem without register scavenger but in that case,
> I'm just pessimistically planning for the case where two emergency slots are
> needed.
>
>
> This function which adjusts the stack pointer is called from the prologue
> and epilogue code. I don't know the size of the stack instruction selection
> and register allocation has taken place so
> I don't know if I need to go to this special mode for adjusting the stack
> early on.
>
> As I'm writing this, I realize that there is a hack that may be safe that I
> could use but would still be interested to know the answer to my question.
>
> The hack that may be okay is this:
>
> When the stack pointer needs to be incremented during function entry
> (prologue generation), I know that registers v0 and v1 (scratch registers
> except at function return) are free.
>
> Similarly, when the stack pointer needs to be incremented during function
> return, I know that registers a0, a1 (argument registers are free).
>
> So I may be able to just know that there will be no problem, i.e. there will
> not even be any call to register scavenger during prologue and epilogue. I
> have to think about this.

We are doing something similar for hexagon (I don't think the code is
in tree, though)  for function prolog/epilog code.