[llvm] TableGen support for RegisterBankInfo (PR #71357)

[Matt Arsenault via llvm-commits]

================
@@ -289,6 +299,138 @@ void RegisterBankEmitter::emitBaseClassImplementation(
      << "} // end namespace llvm\n";
 }
 
+// This emitter generates PartialMappings, PartialMappingIdx,
+// BankIDToCopyMapIdx and BankIDToRegisterClassCount from the .td files.
+// However it requires that the .td files fully describe their RegisterBanks
+// and otherwise emits #error lines for the offending Registers.
+//
+// These tables and enums are enabled by GET_REGBANKINFO_DECLARATIONS,
+// GET_REGBANKINFO_PARTIALMAPPINGS and GET_REGBANKINFO_VALUEMAPPINGS
+// So a backend which doesn't fully describe its RegisterBanks
+// will not break if it doesn't define these macros.
+//
+// This was discussed in https://discourse.llvm.org/t/74459
+void RegisterBankEmitter::emitRBIHeader(
+    raw_ostream &OS, StringRef TargetName,
+    const std::vector<RegisterBank> &Banks) {
+  const CodeGenRegBank &RegisterClassHierarchy = Target.getRegBank();
+
+  OS << "namespace llvm {\n"
+     << "namespace " << TargetName << " {\n"
+     << "enum PartialMappingIdx {\n"
+     << "  PMI_None = -1,\n";
+
+  // Banks and Register Classes are *not* emitted in their original text order
+  int ID = 0;
+  for (const auto &Bank : Banks) {
+    for (const CodeGenRegisterClass *RC :
+         Bank.getExplicitlySpecifiedRegisterClasses(RegisterClassHierarchy)) {
+      OS << "  PMI_" << RC->getName() << " = " << ID++ << ",\n";
----------------
arsenm wrote:

The partial mapping should just be a size. However, I am not sure what the ultimate value of this level of detail provides. As it stands we have a ton of infrastructure to produce a bunch of register sizes, but then they're not actually useful to code that needs to use them. 

RegBankSelect tries to pre-create registers for you with appropriate sizes, but that doesn't preserve the type if you're doing a vector breakdown for example. You also aren't free to just directly use the registers that were created for you, and it doesn't compose with constructing new instructions. For example if you try to split a 64-bit operation into operations on 2 32-bit pieces, you may end up with 2 32-bit registers but you ultimately need to figure out how to undo the split to produce a valid merge instruction 

https://github.com/llvm/llvm-project/pull/71357