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

Quentin Colombet via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 19 17:05:22 PST 2015


qcolombet added a comment.

Hi Dan,

> We have an infinite number of registers, but it's still desirable to minimize the total number of registers, so we're doing coloring.


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.

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?

> I don't understand. The patch here models the registers as live-in to the function[...]. Registers that are live-in to a function are naturally live-in to the entry block.


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?

I think that if I know how the consumer of the web assembly lower the ABI (I.e., my first question), it would be easier to advice on the best way to tackle this.

What do you think?

Cheers,
-Quentin


Repository:
  rL LLVM

http://reviews.llvm.org/D14750





More information about the llvm-commits mailing list