[llvm-dev] Reg units for unaddressable register parts?

[Quentin Colombet via llvm-dev]

> On Sep 28, 2016, at 11:32 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:
> 
> On 9/28/2016 1:20 PM, Quentin Colombet wrote:
>> 
>>> On Sep 28, 2016, at 10:52 AM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>> 
>>> On X86, the registers AX, EAX and RAX all share the exact same register units. In terms of units, there is no difference between these registers. This makes register units insufficient to track liveness, since live AX does not imply live EAX.
>> 
>> That is exactly the intent.
>> If AX is live, you don’t want another value to use EAX or RAX.
> 
> I'm not sure what value you are referring to.

I mean if AX hold some value, we do not want RAX to hold something else otherwise you will clobber AX.

> 
> I have this situation in mind:
>  RAX = ...  (1)
>  EAX = ...  (2)
>  ... = RAX  (3)
> There doesn't seem to be a way to determine whether (1) is live based on lane masks, and to distinguish it from
>  EAX = ...  (1)
>  RAX = ...  (2)
>  ... = RAX  (3)

RegUnit are more for availability checks (check if this register is free/occupied) than proper liveness.
There never was an intent to capture precise liveness per se. I guess you are looking at them in the context of what I said regarding live-in sets. In that context they are ideal because you have a conservative representation of what is available/not available in terms of registers with a compact representation.

Having some reg units for unaddressable register parts may make sense, but generally speaking we had preferred to avoid it because we would have to filter them out for most analysis that deals with RegUnit.

The cases where that it could make sense to use unaddressable register units are:
1. If we want to switch RegMasks to RegUnit (what Matthias explained)
2. If we want to track precise liveness for physical registers
3. If we want to fix the register pressure sets for x86 https://llvm.org/bugs/show_bug.cgi?id=23423

#1 is a cleanup but not rely in the way of anything useful.
#2 is not a problem IMO since most of our work with liveness happens on unallocated code.
#3 would be a nice fix but the overload benefits compared to the infrastructure needed to fix it does not seem worth it.

Cheers,
Q.


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