[LLVMdev] register scavenger

[Reed Kotler]

I ran into another issue with register scavenger.

In my case, I don't need a place on the stack for an emergency spill slot.

I have these free mips32 registers, that are not in general very useful 
for other things, for the emergency spill slot. I can move to and from 
mips16 (subset of mips32) registers and mips32 registers.

I also have a situation where I need two free registers so then the
possibility that two emergency storage places are needed. This can
occur during prologue/epilogue and in some unusual cases during function 
call.

In turns out to be not be simple to add/subtract a large (>16 bit 
constant) to/from SP using one register.

SP is not a mips16 register and there is no way to add another register 
or large constant to it. You have to move SP to a mips 16 register and 
then add the value of another register which has already been loaded
with a large constant. So that means that two registers are needed.

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.

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.

There is another such place where a large stack adjustment could be 
needed, besides prologue and epilogue and I'd have to think more about 
this to know if I could make this work there; but that is such a rare
occurrence that I could take a more pessimistic approach in that one case.


On 11/10/2012 05:09 PM, Reed Kotler wrote:
> You mean when I "explicity" use it by calling methods of register
> scavenger?
>
> Right now I'm just allocating virtual registers that will be resolved by
> the use of register scavenger and I'm also providing an override of the
> virtual method saveScavengerRegister. In Mips16, I have an extra mips 32
> register (not usually very useful since it can only be used
> in a move instruction) I can use instead of having to go to the stack
> for an emergency slot.
>
> On 11/10/2012 04:39 PM, Arnold Schwaighofer wrote:
>> CC the list.
>>
>> On Sat, Nov 10, 2012 at 6:30 PM, Arnold Schwaighofer
>> <arnold.schwaighofer at gmail.com> wrote:
>>> Assuming you use the scavenger in your own code yes.
>>>
>>> A usage could look like:
>>>
>>> for all basic blocks BB:
>>>   RS->enter(BB)
>>>   for all instructions CurrInst in block order:
>>>     if CurrInst has virtual def
>>>       CurrReg = RS->scavenge(CurrInst)
>>>       replace virtual def by CurReg
>>>     else if Insts has virtual use
>>>       replace virtual use by CurReg
>>>     RS->forward(CurrInst)
>>>
>>>
>>> Look at scavengeFrameVirtualRegs in PrologEpilogInserter.cpp for more
>>> detail (I left out some, error checking, etc).
>>>
>>> On Sat, Nov 10, 2012 at 6:15 PM, Reed Kotler <rkotler at mips.com> wrote:
>>>> Thanks!
>>>>
>>>> When you say that the client calls "forward", who do you mean?
>>>>
>>>> Do I need to call forward in addition to marking the use "kill"?
>>>>
>>>> Reed