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

[Krzysztof Parzyszek via llvm-dev]

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