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

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

Thanks for the context Krzysztof.

I agree with Matthias that having a few more unaddressable register units may be
useful, but we don’t want to be exhaustive as it will be bad for performances.

Also, the API is probably not great but have you tried to use
MCRegisterInfo::getSubRegIdxSize, MCRegisterInfo::getSubRegIdxOffset & co.
for your problem?

Out of curiosity, could describe why this is useful to have such precision in
the liveness tracking?

I am not sure I see any use case, especially because I would not rely on the
semantic we have for the target instructions.
E.g.,
RAX = …
EAX = … <— Does this definition clobber the high part of RAX?

Indeed, we do not necessarily describe the exact semantic of an instruction. For
instance, on x86 it is probably right to assume most instruction do not touch
the high bits, but on AArch64 this is the opposite.

What I am saying is that even if we had the infrastructure for the unaddressable
reg units, we would probably need a lot of work to be able to use it.

The bottom line is I would like to see target independent use cases that would
make such investment worth it and so far I haven’t seen that.

Side question, have you check how the scheduler check dependencies for in post
RA mode? I wonder if it is already possible to build the information you want
form the existing APIs.

Cheers,
-Quentin
> On Sep 28, 2016, at 1:13 PM, Krzysztof Parzyszek <kparzysz at
codeaurora.org> wrote:
> 
> 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

On 9/28/2016 7:30 PM, Quentin Colombet wrote:
> I am not sure I see any use case, especially because I would not rely on
the semantic we have for the target instructions.
> E.g.,
> RAX = …
> EAX = … <— Does this definition clobber the high part of RAX?
Short reply right now, regarding this:

Thanks, that didn't occur to me. According to the Intel documentation, 
moving into a 32-bit register zero-extends the value to 64 bits. So in 
the example above, EAX=... would indeed overwrite the high half of RAX.

It seems that targeting any part of the lowest 16 bits (or all of them) 
preserves the rest, while changing the second-lowest 16 bits (16..31) 
does affect bits 32..63.

-Krzysztof

On 9/28/2016 7:30 PM, Quentin Colombet wrote:
> Out of curiosity, could describe why this is useful to have such precision
in the liveness tracking?
RDF is meant to allow optimizations across the whole function. As a 
result, registers may change between basic blocks, and there is code to 
recalculate it. Accuracy is required to avoid unnecessary block live-ins.
For example, calculate live-ins to BB1:
   BB#1:
     R0 = ...  // Does not affect R1
     ... = D0  // D0 is a pair R1:R0
Here we want R1 to be the live-in, but not the whole D0 or R0.
At the same time, on x86-64,
   BB#1:
     EAX = ...
     ... = RAX
RAX would not be a live-in (since EAX=... overwrites all bits in RAX).


One potential target optimization (for Hexagon) would do with register 
renaming. To rename registers we would have to isolate their live ranges 
very accurately.

> Indeed, we do not necessarily describe the exact semantic of an
instruction. For instance, on x86 it is probably right to assume most
instruction do not touch the high bits, but on AArch64 this is the opposite.
That's not necessary. In the x86-64 case, if EAX had an extra reg unit 
that it would share with RAX (for the unaddressable part extending from 
bit 16 upwards), then none of AL=, AH=, or AX= would invalidate the rest 
of EAX and RAX, while EAX= would, since it would store into the
"hidden"
reg unit.

The fact that RAX ends up with 0s in the high part would not be 
exploited by any target-independent code.

The problem is that at the moment, the last instruction in
   EAX = ...
   AX = ...
   ... = EAX
would seem to only use the value from the second one, since AX= defines 
all lanes/units that EAX has. This kind of inaccuracy is not just 
suboptimal, it would lead to an incorrect conclusion. Currently, only 
x86-specific knowledge would tell us that the first instruction is still 
live, and I'd like to be able to tell by examining lane masks/reg units.

> What I am saying is that even if we had the infrastructure for the
unaddressable reg units, we would probably need a lot of work to be able to use
it.
Maybe I have overstated the degree of complexity of what I'm looking 
for.  The information I'm interested in is: "what part of the 
super-register survives a definition of a subregister". And the "what 
part" does not have to be precise in terms of exact bits, but just some 
identification like a bit in a lane mask.

> Side question, have you check how the scheduler check dependencies for in
post RA mode? I wonder if it is already possible to build the information you
want form the existing APIs.
It checks register aliasing.  If two registers are aliased, there will 
be a dependency between them.


-Krzysztof

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