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

Quentin Colombet via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 20 13:11:38 PST 2015


qcolombet added a comment.

Hi Dan,

> Also, if there is another way to solve the problem, I'd be very interested to hear more about it.


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?

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?

My problem with the approach is that the scope seems so narrow that it feels to me like a hack.
E.g.,

1. /// 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?
Say you have:
foo(v1)
if ()

  v3 = ...
  v2 = phi(v1, v3)

Which gives after coalescing:
foo(v1)
if ()

  v1 = ...

How do you represent that?

In particular, we will see only one def if we start iterating over the def-uses.

1.

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.

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

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.

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

> Generalizing the concept of physregs to support variable numbers of physregs would be another possible solution. Would you prefer that?


I admit I would prefer that.

Cheers,
-Quentin


Repository:
  rL LLVM

http://reviews.llvm.org/D14750





More information about the llvm-commits mailing list