[LLVMdev] TargetRegisterInfo and "infinite" register files

[Villmow, Micah]

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Jakob Stoklund Olesen
> Sent: Tuesday, May 17, 2011 2:25 PM
> To: Justin Holewinski
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] TargetRegisterInfo and "infinite" register files
> 
> 
> 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.
[Villmow, Micah] We did this in our backend from LLVM 2.4-LLVM 2.8, it caused more problems than I can remember because LLVM
changes quite often and many times the functionality that we were relying on was either removed or modified in a way that
didn't work for us, making integration a pain. I'd advise against this approach unless you are willing to
keep track of and maintain all of the changes to LLVMTargetMachine.cpp in your own version.

> 
> 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.

[Villmow, Micah] We also tried this approach with the AMD backend, by creating our
own register allocator that just ran a few passes but didn't actually allocate registers out of virtual.
There are passes in the backend that don't like virtual registers, i.e. From MachineLICM.cpp.
"assert(TargetRegisterInfo::isPhysicalRegister(Reg) &&
           "Not expecting virtual register!");"
> 
> > 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
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev