[PATCH] D14750: Support for function-live-in virtual registers

[Dan Gohman via llvm-commits]

sunfish added a comment.

> I am not sure what to suggest given that I do not know all the parameters of the problem.

>  In particular, what does it mean for WebAssembly to color?


It's the same thing as lib/CodeGen/StackSlotColoring.cpp, but with virtual registers instead of stack slots. Here's the code:

http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/WebAssembly/WebAssemblyRegColoring.cpp?revision=253626&view=markup

The only tricky part is moving ARGUMENT instructions back to the top of the function and recomputing liveness, and that's the very code that the patch here is seeking to eliminate.

> You are saying that you have an infinite number of physical registers, but on the other hands we don't support having a variable number of physical registers. How does this work?


The machine has infinite registers. We currently model them in LLVM with virtual registers.

> > Return the machine basic block that contains the definition of the / specified virtual register or null if none is found. This assumes that /// the code is in SSA form, so there should only be one definition. MachineBasicBlock *getVRegDefMBB(unsigned Reg) const;




> What happen when the code is not in SSA anymore?


getVRegDefMBB is modeled directly after getVRegDef which already exists and already works this way. All uses of getVRegDefMBB were previously users of getVRegDef.

That said, this did prompt me to notice a bug; getVRegDef returns nullptr if the register has multiple defines; I've now updated the patch to make getVRegDefMBB check the same condition.

> The only place where virtual registers can be live-in are function entry and this is never called out and it is not future proof IMHO.

>  For instance, what will happen when you will want to model things like:

>  invoke foo landing pad bb1

> 

> The virtual registers for the landing pad (i.e., the arguments of the funclet) would need to be live-in of bb1 only, if you want a precise liveness.


This is a basic asymmetry that already exists; machine basic blocks don't track virtual registers in their live-in sets.

Also, the return value of the call is not live across the unwind edge, so we're not going to be tempted to specially create newly live virtual registers along that edge.

> All of these sounds to me like we do want physical register semantics, but we are not willing to pay the price for it.


What do you mean by "physical register semantics"?

> So yes, I would certainly prefer having a variable number of physical registers and I do understand this is much more involved. For now, the proposed approach looks more error prone to me than the current implementation with the ARGUMENT instruction, where the scope is limited to web assembly and where the generic passes know how to deal with it (modulo the placement problem).




> What about an attribute or something that says don't move those instructions?

>  I am guessing we must have something similar for barrier like instruction.


It's not easy to do, because it isn't enough to say "this instruction can't move", because we also need to say "other instructions can't move past this one, even if they have no side effects". And if we say that, then we have to think about whether it's valid to do MachineLICM, MachineCSE, or even register allocation itself in the vicinity of such a powerful instruction. It would end up being a fairly complex mechanism.

> > Perhaps this assymetry could be said to be a reflection of the assymetry in the way LiveVariables and LiveIntervals track liveness of virtual versus physical registers.




> To be fair, those two liveness tracking are used differently and I think it would be nice to kill the LiveVariables at some point.


The following asymmetry in the MIR data structures already exists:

        Machine  MBB     MF
        Operand  LiveIn  LiveIn
       +-------+-------+-------+
  Phys |   Y   |  Y    |   Y   |
  Virt |   Y   |  N    |   N   |

My change would change the Func LiveIn column for virtual registers. This isn't introducing any new asymetry.

In fact, it's increasing symmetry because a register lifetime can start either at an instruction or before the function starts.


Repository:
  rL LLVM

http://reviews.llvm.org/D14750