<div dir="ltr"><div>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.</div><div>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. <br></div><div>So, I'd expect programmers to create two different RegisterClasses and "associate" them with the Processor(Model).</div><div>IMHO, this modular design allows separation of concern and composability for subtargets.</div><div> <br></div><div>However, it does not seem so.</div><div><br></div><div><br> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 28, 2021 at 2:16 AM Quentin Colombet via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Hi,<div><br></div><div>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).</div><div><br></div><div>Now assuming target2 is a strict super set of target1, there is actually a simpler approach:</div><div>- Have one register class for all 2048 gprs</div><div>- Mark the 1024 top gprs as not “reachable” for target1</div><div><br></div><div>You could do that by simply modifying TargetRegisterInfo::getReservedRegs.</div><div><br></div><div>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.</div><div><br></div><div>Take a look at <span style="font-family:Menlo;font-size:11px">X86RegisterInfo::getReservedRegs </span>for instance.</div><div><br></div><div>Cheers,</div><div>-Quentin</div><div><br><div><blockquote type="cite"><div>On May 27, 2021, at 11:41 AM, jeniffer lesley via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr"><div>Hi</div><div>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?</div><div><br></div><div>If this is not the right way then can someone please educate?</div><div><br></div><div><br></div><div>Thanks<br></div></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><i style="font-size:12.8px">Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this mail are of my own and my employer has no take in it. </i><br></div><div>Thank You.<br>Madhur D. Amilkanthwar<br><br></div></div></div>