llvm dev - Sep 2016 - Reg units for unaddressable register parts?

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 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)

-Krzysztof

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

> 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

On 9/28/2016 2:59 PM, Quentin Colombet wrote:
> The cases where that it could make sense to use unaddressable register
units are:
>
> 2. If we want to track precise liveness for physical registers
>
> #2 is not a problem IMO since most of our work with liveness happens on
unallocated code.
This is what I'm working on (RDF). I generate a data-flow graph for 
physical registers, and I need to be able to accurately connect defs to 
uses.
Currently it has target-specific hooks to determine covering, and the 
only target hook for now is for Hexagon. The generic code is not very 
precise and using lane masks would
(1) simplify some parts of the code quite a bit,
(2) make it work better for other targets.

There are post-RA optimizations that this would enable, at least for 
Hexagon. We already have 1 specific consumer, aside from some simple 
copy propagation/dce, and there will likely be more.

So far it's been developed on Hexagon (and is under lib/Target/Hexagon). 
Vivek Pandya offered to do some work to make it available for all targets.

-Krzysztof

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