[llvm-dev] Reg units for unaddressable register parts?
Krzysztof Parzyszek via llvm-dev
llvm-dev at lists.llvm.org
Thu Sep 29 07:45:07 PDT 2016
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:
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,
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
> 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"
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.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
More information about the llvm-dev