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

[Dan Gohman via llvm-commits]

sunfish added a comment.

> So you technically don’t have a clobbering problem. You would just like to have them appear at the beginning of the function so that it is easier for the consumers of the web assembly IR to lower the ABI properly.


We actually want to color these registers along with the other registers, and this requires us to have precise liveness information.

> What am I saying is that the constraints you have are soft. You could imagine a different way of telling the consumers of the web assembly IR what are the arguments of the function.

>  By the way, if you get rid of those ARGUMENT instructions, how do the consumers of the web assembly IR know what they have to lower for the ABI?


The signature of a function is explicit, so a consumer knows how many arguments there are. In a function with N arguments, the first N register numbers are the arguments (the numbering is not LLVM's virtual register numbering). Other than being initialized to the incoming argument values, these registers thereafter are identical to regular registers.

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

> Yes, but what I am saying is that you are restricting the notion of live-in for a virtual register to the entry block, whereas the one for physreg applies to all blocks. This is this asymmetry that I feel is wrong.

>  Wouldn’t it make sense to instead generalize the notion of physreg for your goals?


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.

Generalizing the concept of physregs to support variable numbers of physregs would be another possible solution. Would you prefer that? I expect it would require much more invasive changes.


Repository:
  rL LLVM

http://reviews.llvm.org/D14750