[LLVMdev] register scavenging

Reed Kotler rkotler at mips.com
Tue Feb 5 14:51:51 PST 2013


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.




More information about the llvm-dev mailing list