[llvm-dev] Reserved/Unallocatable Registers

[Quentin Colombet via llvm-dev]

Hi Krzysztof,


> On Feb 27, 2016, at 7:46 AM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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?

This was our conclusion with Matthias from our latest offline discussion.
I believe he will send an updated version to reflect that.

Cheers,
-Quentin

>  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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev