freenode/#sicl - IRC Chatlog
Search
14:04:17
beach
I think to the EDU calculation I should add some "probability" that the next use of a variable is going to be after a function call. If, at a particular program point, that probability is zero, then any register can be assigned to it. The higher the probability, the more likely it is that a callee-saves register will be assigned to it, or that it will be spilled.
14:38:47
beach
One complicating factor that I took into account in the description of the register allocator in the SICL specification was information about whether a variable is next needed in a specific register. I put that in for the function-call protocol. But with call-site optimization, it doesn't matter what register is used, or even whether a register is used. So I am going to take that out.
14:41:03
beach
And, by the way, the call-site optimization technique means that 1. Most of the time, no particular register needs to be reserved for argument passing and 2. That any register can be used to pass arguments, so we can have many more arguments passed in registers than with a small and fixed set of registers reserved for this purpose.
14:41:33
beach
The more I think about it, the more I am convinced this technique is going to be dynamite.
14:47:13
beach
Let's see, instructions such as MOV just moving one register to another register ought to be very cheap, because of things like register renaming, right?
14:48:36
beach
If so, that means that in a loop, as long as variables are kept in *some* register, it is OK if the back arc has to shuffle some registers around.
14:50:31
beach
I am saying that, because another reason I had for the information about a variable needed in a specific register was for back arcs, where a register had already been assigned to a variable.
14:52:17
beach
But if a variable is needed frequently in a loop, it is likely to stay in the register it was first allocated to. And if it is cheap to occasionally get it wrong, then I am not going to complicate things by taking that possibility into account.
15:08:32
beach
There! Now the description is sufficiently small that there is some hope to get the implementation right.
15:58:17
heisig
If I understood correctly, the most recent AMD CPUs will even attempt to place the topmost stack entries in virtual registers.
15:59:30
heisig
It is actually quite hard (because of x86's bizarre semantics). They only managed to get it to work for some cases.
16:03:39
heisig
I am optimistic - it is only natural that architectural details become important now that manufacturing hits its limits.