[llvm-dev] Allowing virtual registers after register allocation

[Derek Schuff via llvm-dev]

On Thu, Dec 10, 2015 at 2:46 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.
>

Indeed, we are accumulating exactly this experience now, having started
with VRegs, as that seems like a more natural fit conceptually. The problem
is that we are essentially blocked on this (obviously lack of
PEI/frameindex elimination blocks a lot of things) so in order to make
further progress and get further experience we will need either a simple
change something like the one proposed or to do what NVPTX did and just
make our own copy of PEI.


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

This is what Dan is trying to address with http://reviews.llvm.org/D14750.
The discussion on that change is essentially the same as the one going on
here.


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

I believe this would be addressed for wasm with a mechanism like that in
D14750 (or the current special ARGUMENT pseudos we have now) in combination
with the fact that we remap the virtual registers into a different number
space in a way that takes the arguments into account, just before emission.

- regmask clobbers only affect physregs
> (- You cannot reuse the existing regalloc infrastructure, but IMO that's
> not a good idea anyway for virtual ISAs)
>

Agreed.


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

This seems like a really big deal to me; plus a lot of the discussion above
e.g. with regard to what the behavior of the pysical register classes, is
about properties which are really only relevant for register allocation
(and again I think we agree that we probably don't want to be using the
normal register allocator anyway).


> - 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.
>
> I think you are right.


> 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).
>
>
 Perhaps it would be worthwhile to flesh out a bit more precisely what
semantics are required.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151210/127018a1/attachment.html>