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

[Quentin Colombet via llvm-commits]

qcolombet added a comment.

Hi Dan,

Thanks for your patience, taking some time to catch up :).

> What do you mean by "physical register semantics”?


I mean having a register live-in of a function. This is not something that, at least, I expect from a virtual register.
It may be quite of a stretch, but the reason is because those live-ins have in fact several definitions, i.e., the setting of the arguments in each caller, whereas virtual registers are supposed to have just one (in the case of live-ins of a function, a reasonable representation, though not practical, would be a phi of each argument from the callers). The physical registers are IMO a cheap and accurate way to pieces the different live-ranges together.
That is why I believe this is better represented if it stays in the "physical register” semantic world.

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


That is what I am saying and here, to me, we are making things worse, because we do not have such tracking but for the entry block. The fact that you said it is the live-in of the function instead of the live-in of the basic block is a subtle difference that may bit us.

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


Agree, but I don’t like the distinction between live-in of basic block and live-in of function. Right now, both physical and virtual registers are consistent with this respect, i.e., both have either have basic block *and* function live-in semantic available or basic block *and* function live-in semantic *not* available!

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


I disagree, this introduces a more subtle dissymmetry.

To summarize, I really believe the way to go is to being able to change the number of physical registers dynamically, without impacting the compile time of the targets that know this number statically. Another option could be to change the way we represent phi to go toward a swift IR like representation, i.e., arguments of basic block and use that on the entry block.

I reckon both options are involved, but I guess we are not in a hurry, so we can shot for the proper fix :).
Personally I prefer the physical registers approach.

Cheers,
-Quentin


Repository:
  rL LLVM

http://reviews.llvm.org/D14750