[llvm-dev] Allowing virtual registers after register allocation

[Dan Gohman via llvm-dev]

On Thu, Dec 10, 2015 at 3:38 PM, Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> > >You're right that we don't really want infinite register classes,
> > >but rather, we
> > >want "expandable" ones. Making extra-large register classes that are
> > >restricted by having most of the registers in the reserved set,
> > >however,
> > >seems just as much a hack (and a worse one in many ways).
> >
> > Whether it’s a hack or not depends on the sizes in question. Existing
> > X86 already has this property for 64 bit, there are registers which
> > simply don't exist
> > unless the target arch is 64 bit.  If WebASM folks are thinking of
> > allocating down to something like 32 or 64 registers, with maybe a
> > maximum of 128 or 256, then
> > making some portion of this reserved when a tighter allocation (only
> > coloring to 16 or 32) seems completely doable (and natural) using
> > all existing infrastructure, with nothing
> > special needed.
>
> No argument from me on this point, however, whether or not a
> relatively-small fixed number is acceptable I don't know. What does seem to
> be the case, however, is that they need some kind of register use cost
> function which makes the use of each new register increasingly expensive
> and/or the ability to dynamically change the number of registers that are
> reserved at any given time. The former is probably better.
>

A relatively-small fixed number is indeed not acceptable. We have a virtual
ISA which is general-purpose and is not inherently afraid of having
thousands of registers and perhaps more, if that's what the program
actually needs. We do use coloring to reduce the number as we can, but
coloring can't always fix everything without spilling.

And whether we ever have LLVM spill, as opposed to just using more
registers, is a decision we'd like to make based on the needs of the
platform, not based on any limitations of LLVM. Right now, the working
assumption is that LLVM should not spill.


>
> > If getting into significantly larger numbers, then I
> > can see where this might be considered a hack.  But unless you are
> > talking about multi-thousands,
> > it does beg the question about what the extra generality is worth
> > compared to the engineering effort to design, implement and support
> > it.
>
> This is exactly why I was in favor of reusing the existing infrastructure
> for virtual registers.
>

The virtual register infrastructure in LLVM turns out to be a very close
fit for our needs. The main alternative is effectively to take LLVM's
physical register concept and evolve it in the direction of being more like
its virtual register concept in several significant ways. It's not clear
that LLVM should really want two different concepts with so much
similarity, but also numerous subtle differences.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151210/b4266606/attachment.html>