[llvm-dev] Reserved/Unallocatable Registers

[Krzysztof Parzyszek via llvm-dev]

On 2/26/2016 7:09 PM, Quentin Colombet via llvm-dev wrote:
> To summarize my thoughts, I believe reserved registers were introduced
> to fill the gap of want we don’t model. E.g., for pc for instance, each
> instruction should implicitly define it, then the actual use are
> predictable. Since we don’t do that, we need to conservatively assume
> that the value of a reserved register is unknown and that rule #4 is not
> true.

Maybe we need to extend the model then?  From the point of view of 
register allocation, none of these registers are allocatable, so nothing 
would change, but from the point of view of scheduling, for example, 
certain moves involving reserved registers are legal, while others are not.

For example:
1. Status (flags) register, such as the one in x86: it's a special 
register, but it cannot be modified except by an instruction that is 
known to alter it. (I know there was no direct copy from flags to a 
register on x86, but I can't think of a better example.)  Dependencies 
on this register need to be respected.
   a. Special cases: Hexagon has USR (user status register), where one 
of the bits indicates "overflow". This bit is sticky and can only go 
from 0 to 1, except where it's cleared explicitly. Stores to this bit of 
the register can be reordered (except the "clear bit" case).[1]

2. Timer/cycle count registers, PC, etc.: these registers are "volatile" 
in the sense that they are modified in a way that does not depend on the 
semantics of the executed code in a predictable or controllable manner. 
Dependencies on such registers can be ignored, and two subsequent reads 
of their value are not guaranteed to be equal.
   a. Special case: one could imagine a special register, the reading of 
which in itself can have side-effects. In such case the reads should not 
be elinminated or duplicated.


[1] In our local repository we have a hook in the subtarget info, which 
is called with the DAG as its argument after its construction, and where 
we remove the write-write dependencies on the overflow bit (which we 
model as a subregister of USR). This is really important for us for 
performance reasons, and it would be great to have an "official" way of 
handling such cases.


-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation