[llvm-dev] Allowing virtual registers after register allocation

[Jim Grosbach via llvm-dev]

> On Dec 10, 2015, at 2:45 PM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> To say this first: This whole discussion about using virtregs until emit or having growable physregs is hard to argue without actually having experience trying to go either way.
> 
> Problems when using virtregs throughout the backend until emit time:
> - The MC layer is using MCPhysReg (which is an uint16_t) and would need retrofitting to support virtregs
> - VirtRegs are assumed to have a definition, physregs can appear "out of thin air" in some situations like function parameters, or exception objects appearing in a register when going to a landingpad.
> - VirtRegs are assumed to be interchangeable, replaceing vreg5 with vreg42 shouldn't affect the program semanic (given they both have the same register class and we have no other defs/uses of vreg42), if you use virtregs for parameter passing this won't be true anymore
> - regmask clobbers only affect physregs
> (- You cannot reuse the existing regalloc infrastructure, but IMO that's not a good idea anyway for virtual ISAs)
> 
> Problems when allowing the dynamic creation of physregs:
> - The current assumption of all register being known at tbalegen time will mean that we probably need bigger changes to support dynamically growing physreg lists and it may take a while until we have flushed out all places that relied on a fixed-register number assumption.
> - You probably do not want to compute/modify some information like register class subsets/supersets. However as far as I can see we do not need subregister support for the virtual ISA usecase and may be fine just not allowing the combination of subregs with dynamic physreg creation.
> 
> Non-Issues:
> - Liveness calculation should work as well with virtregs as with physregs
> 
> All in all it seems to me like using virtregs until emission time may take less engineering effort to a point where it is 95% working, but will be a pain to maintain in the long term because we suddenly have physreg like semantics on virtregs for some targets (but not for "normal" ones).


I agree with this (and with Quentin). Perpetuating virtual registers further down the is pretty deeply troubling to me. It could certainly be made to work, but I don’t think it’s the right way to go.

> 
> - Matthias
> 
>> On Dec 10, 2015, at 1:13 PM, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>>> 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.
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev