[LLVMdev] register scavenging

[Reed Kotler]

So what I realized is that you can't use the simple scavenger trick 
where you create the virtual register and use the more advanced features.

This is because you can't call forward() in any form if there are 
virtual registers being used by any of the instructions in the basic 
block. This will cause forward to fail.

Maybe this is a bug in forward()


On 02/05/2013 02:51 PM, Reed Kotler wrote:
> Does not seem that anyone is using the more advanced features of
> RegScavenger
>
> On 02/05/2013 01:09 PM, reed kotler wrote:
>> I ran into a case in Mips16 where I need two registers.
>>
>> The problem arises from the fact that SP is not a mips16 register.
>> You can implicitly use it in load/store and, move it to/from a mips16
>> register and add small immediate values to it but that's it.
>>
>> It's not in general a problem for me because there are a bunch of mips32
>> registers that are hard to use in mips16 so at this time, I only use
>> them in special situations. So they are convenient for temporarily
>> storing mips16 registers.
>>
>> mips16 registers is a subset of the full mips32 register set.
>>
>> so i'm guessing that I can still use the RegScavenger class for this.
>>
>> I'm thinking of something [not sure if this is a correct understanding
>> of this API]
>>
>> RegScavenger rs;
>> rs.enterBasicBlock(MBB);
>> forward(II);
>>
>> and then I can get and set available registers????
>>
>> Ideally I could use usual way to get the first register I need by
>> implementing the virtual function for register scavenging in
>> Mips16RegisterInfo [which I already do] and just roll my own for this
>> one moment to get an additional register. If there are no free
>> registers, I can save one in an unused mips32 only register.
>>
>> What I need is somewhere to move SP so that I can use it in another
>> instruction.
>>
>> mov unused mips32 register, temp mips16 register; if temp is being used
>> mov temp mips16 register, SP
>> add.....temp mips16 register....
>> ; temp is no longer needed
>> mov temp mips16 register, unused mip32 register ; if temp was being used
>>
>> This is my main problem.
>>
>> ----------------------------------------------------------------------
>> There is another issue from the point of view of optimization and that
>> is that if I'm going to be
>> doing this a lot, then this copy of SP is a CSE and should be treated as
>> such. Of course, we don't
>> know to do this until the end.
>>
>> I think there is an earlier llvm pass which gives a better estimate of
>> local stack size so I could
>> make this decision earlier and allocate an alias for SP in a mips16
>> register.