[LLVMdev] TargetRegisterInfo and "infinite" register files

[Justin Holewinski]

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>