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

Quentin Colombet via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 29 17:48:27 PDT 2016

> On Sep 29, 2016, at 5:23 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:
> On 9/29/2016 9:45 AM, Krzysztof Parzyszek via llvm-dev wrote:
>> 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.
> Quentin,
> If such units were something that targets could explicitly request via some construct in a .td file, would you find that acceptable?

Quick thought (I haven’t had time to look closely to your other emails).

If we add some explicit construct in the .td files, how could we use them?

Basically, I am wondering if say in RDF we would you have some mode where we check for that property to be on and support two different modes, or we would have everything working on RegUnit and if we don’t use the unaddressable mode in the td files, we get conservative answers (due to the nature of RegUnit)?

The reason I am asking is because I believe it may already be possible to add unaddressable register units by hand.
One would need to create additional subregs in their td file to fill the holes, then mark all the registers mapping to those subregs as unallocatable.

let SubRegIndices = [sub_16bit] in {
def EAX : X86Reg<"eax", 0, [AX]>, DwarfRegNum<[-2, 0, 0]>;

let SubRegIndices = [dummysubIdx_16bit, sub_16bit] in {
def EAX : X86Reg<"eax", 0, [ADummyXH, AX]>, DwarfRegNum<[-2, 0, 0]>;
def DummyRegClass : RegisterClass[…]/*list all dummy regs*/ {
isAllocatable = 0;

In other words, you may be able to explore if that would solve your problem or if we have to come up with something smarter.

> -Krzysztof

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160929/41ee9e6c/attachment.html>

More information about the llvm-dev mailing list