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