[LLVMdev] TargetRegisterInfo and "infinite" register files

Jakob Stoklund Olesen stoklund at 2pi.dk
Tue May 17 14:25:09 PDT 2011


On May 17, 2011, at 2:10 PM, Justin Holewinski wrote:
> I plan on eventually implementing both and seeing which works best for different types of input.
> 
> If virtual registers are used, how do you disable final register allocation in the back-end?

If post-RA passes have trouble with virtual registers, you probably need to implement your own addCommonCodeGenPasses() method.

Alternatively, implement a trivial register allocator that simply runs 2-addr, phi-elim, and coalescing.

>  Looking through the different Target* classes, I do not see any way to disable it.  I imagine the TargetRegisterClass implementations are still needed to determine legal virtual register types, but are physical register definitions still needed? This would seem to defeat the purpose of using virtual registers in the first place.  Unfortunately, there do not seem to be any documentation (or even existing back-ends) using this approach.

That's right. What you are doing is very different from what a 'real' target requires, so you should probably try to figure out which passes make sense for a GPU back-end.

> For the stack slot approach, what exactly are the semantics of the foldMemoryOperandImpl method?  And how does it relate to the storeRegToStackSlot and readRegFromStackSlot methods?  Do the storeReg/readReg methods generate the (load/store) spill code and the foldMemoryOperandImpl method combine the generated loads/stores directly into the instructions that reference them?

When a register is spilled, the register allocator first tries foldMemoryOperand on all instructions using the register. If successful, the target creates an instruction that accesses the stack slot directly (as is possible on x86 and other CISC architectures). If it fails, the register allocator creates a new tiny live range around the existing instruction, and uses storeRegToStackSlot and readRegFromStackSlot to spill and reload that new register around the instruction.

/jakob




More information about the llvm-dev mailing list