[llvm-dev] Modelling registers per subtarget

[Nemanja Ivanovic via llvm-dev]

I think that similarly to what Quentin suggested, it is very
straightforward to define the full register class and use `AltOrders` and
`AltOrderSelect` in the definition of the register class.
The alternate allocation order would be just the 1024 registers and the
selector would be just a check of the subtarget.

Nemanja

On Fri, May 28, 2021 at 9:36 AM Madhur Amilkanthwar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Ideally, I'd expect this to be a part of ProcessorModel or Processor in
> Target.td. Logically, a Processor(Model) is a group of chip-specific things
> and registers should not be an exception here.
> On the other side of what Quentin said, the two subtargets could be
> mutually exclusive from a register file perspective and even register names
> could be different.
> So, I'd expect programmers to create two different RegisterClasses and
> "associate" them with the Processor(Model).
> IMHO, this modular design allows separation of concern and composability
> for subtargets.
>
> However, it does not seem so.
>
>
>
> On Fri, May 28, 2021 at 2:16 AM Quentin Colombet via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> I could be wrong but the register hierarchy doesn’t really take into
>> account subtargets, instead you can, like you said, create different
>> register classes for them, then have different sets of instructions for
>> each of the subtarget (e.g., take a look at how GR16 vs. GR16_NOREX are
>> modeled in X86).
>>
>> Now assuming target2 is a strict super set of target1, there is actually
>> a simpler approach:
>> - Have one register class for all 2048 gprs
>> - Mark the 1024 top gprs as not “reachable” for target1
>>
>> You could do that by simply modifying TargetRegisterInfo::getReservedRegs.
>>
>> Note: even if you use the register class approach with different
>> instructions, you’ll need to modify that function to “disable” the top
>> registers for target1 anyway. Otherwise you may end up with “out-of-bound’
>> registers (w.r.t. target1) in things like copies.
>>
>> Take a look at X86RegisterInfo::getReservedRegs for instance.
>>
>> Cheers,
>> -Quentin
>>
>> On May 27, 2021, at 11:41 AM, jeniffer lesley via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hi
>> For my toy architecture, I have two subtarget, target 1 and target 2.
>> Target 1 has 1024 and Target2 has 2048 GPRs. How do I model them in .td
>> files? Should I just create a RegisterClass for them? If so, how do I
>> associate them with SubtargetFeature or ProcessorModel?
>>
>> If this is not the right way then can someone please educate?
>>
>>
>> Thanks
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
> --
> *Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this
> mail are of my own and my employer has no take in it. *
> Thank You.
> Madhur D. Amilkanthwar
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210528/9402c60a/attachment.html>