llvm dev - May 2011 - [LLVMdev] TargetRegisterInfo and "infinite" register files

On May 17, 2011, at 11:32 AM, Andrew Clinton wrote:
> On 05/17/2011 12:54 PM, Jakob Stoklund Olesen wrote:
>> What you can do instead is:
>> 
>> 1) Just use virtual registers and skip register allocation, or
>> 
>> 2) Allocate to a small register file, implement memory operand folding,
and pretend that spill slots are registers.
>> 
>> /jakob
>> 
> 
> Empirically, 1) is not true.  The linear scan register allocator appears 
> to do a very good job of reusing registers that have been killed.  It 
> also automatically inserts copies for operations that clobber register 
> operands, and coalesces identity register moves.
Good point. The 2-addr, phi-elim, and coalescer passes are definitely helpful.

The final register allocator pass that assigns physical registers probably
doesn't help you much.

/jakob

On Tue, May 17, 2011 at 2:52 PM, Jakob Stoklund Olesen <stoklund at
2pi.dk>wrote:
>
> On May 17, 2011, at 11:32 AM, Andrew Clinton wrote:
>
> > On 05/17/2011 12:54 PM, Jakob Stoklund Olesen wrote:
> >> What you can do instead is:
> >>
> >> 1) Just use virtual registers and skip register allocation, or
> >>
> >> 2) Allocate to a small register file, implement memory operand
folding,
> and pretend that spill slots are registers.
> >>
> >> /jakob
> >>
> >
> > Empirically, 1) is not true.  The linear scan register allocator
appears
> > to do a very good job of reusing registers that have been killed.  It
> > also automatically inserts copies for operations that clobber register
> > operands, and coalesces identity register moves.
>
> Good point. The 2-addr, phi-elim, and coalescer passes are definitely
> helpful.
>
> The final register allocator pass that assigns physical registers probably
> doesn't help you much.
>
>
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?  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.

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?



> /jakob
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110517/f98e263d/attachment.html>

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

Hi, Justin

  Have you read Helge Rhodin's thesis "A PTX Code Generator for
LLVM"?
He took a quite different approach as yours. I don't know if it can
give you some insight.

  Here is his project website.
  http://sourceforge.net/projects/llvmptxbackend/

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667