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

[Quentin Colombet via llvm-dev]

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