[llvm-dev] Allowing virtual registers after register allocation

[JF Bastien via llvm-dev]

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


We aren't talking about have 32 or 64 virtual registers. Most functions
should have just a few, but we are talking about having as many as the
compiled code needs: the VM will spill what's needed to a shadow stack
that's not user-accessible. This has interesting security properties, lets
the VM do this as optimally as it sees fit for the target ISA, and would
otherwise require the LLVM backend to emit an alloca which we then
translate to a heap allocation to the user-accessible "stack" (which lives
in their heap).

Put another way: it seems sensible for a virtual ISA to have virtual
registers ;-)

I think Derek's proposal is sensible in that it doesn't have much cost to
the LLVM code base, and NVPTX shows precedent for working around that
limitation. We'd like virtual ISAs to be supported as first-class targets,
that has a small cost in LLVM's generality but should help remove hacks in
other virtual ISA implementations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151210/53b6c6ff/attachment.html>