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

[Dan Gohman via llvm-commits]

sunfish added a comment.

> Since you have an infinite number of registers, how do you end up with other registers > clobbering the arguments registers?

>  Are these arguments registers actual physical registers?!


We have an infinite number of registers, but it's still desirable to minimize the total number of registers, so we're doing coloring. It's similar to stack slot coloring; there are an unbounded number of stack slots, but it's desirable to minimize the total size of the stack.

> To be frank, I do not like the approach that’s why I would prefer to understand what are the

>  constraints of the problem first.


We have arguments which are virtual registers. They are conceptually live-in to the function. How should we model this?

Right now we are modelling this with instructions in the entry block that define the values. This is not robust because the scheduler can move them below other instructions. Modelling them as live-in to the function would be a very natural way to express what we mean here.

> That being said, let me comment a bit on the proposal. You are restricting the live-in


information to the entry block and that sounds wrong. Indeed, I guess if you go down that road, you want to model arguments of landing pad the same way and the related blocks are not the entry block anymore!

I don't understand. The patch here models the registers as live-in to the function, using the same live-in mechanism that already exists in CodeGen for physical registers. Registers that are live-in to a function are naturally live-in to the entry block.


Repository:
  rL LLVM

http://reviews.llvm.org/D14750