[MC] Store target Insts table in reverse order. NFC.

[foad]

Summary

This will allow an entry in the table to access data that is stored
immediately after the end of the table, by adding its opcode value
to its address.

[arsenm]

llvm/include/llvm/MC/MCInstrInfo.h

65–66

Can the -1 be avoided?

llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp

2506–2508

Why can't this one use the usual MCInstrInfo::get?

[foad]

llvm/include/llvm/MC/MCInstrInfo.h

65–66

Yes, MCInstrInfo could store Desc + NumOpcodes - 1 instead of just Desc.

llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp

2506–2508

This is a method of ARMOperand, and it seems these addXXXOperands methods do not have access to the ARMAsmParser. I wanted to raise this with @simon_tatham who added this code in D62669. I wonder if this functionality could be reimplemented in an AsmMatchConverter instead. But I don't know if that is possible because I don't understand what this code is doing.

[foad]

Store pointer to last entry in table for simpler indexing.

[simon_tatham]

llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp

2506–2508

And I don't know what an AsmMatchConverter can or can't do, so we may have a problem on both sides here :-)

There's a long explanation of the vpred_n and vpred_r operand classes in a comment in ARMInstrFormats.td. The general idea is that many MVE vector instructions which compute a value and store it in a vector register also come in a predicated form, in which the P0 predicate register indicates which lanes of the output register should be written with the results of the computation, and which should retain whatever data they contained before the instruction. To model this in a MachineInstr in a way that shows the data flow, it's necessary to provide the previous value of the output register as an input, and then tie them to each other so that register allocation will make them the same physical register.

So, at the MC layer, the upshot is that this input operand has to contain the same physical register number as the output operand it's tied to. But this predication system applies to many instructions, with different arrangements of other operands. So this code searches the instruction description to find the tie, in order to find the output operand that already contains the right register number, so as to copy it to the matching input operand.

[simon_tatham]

llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp

2506–2508

Here's a concrete example. If you run llvm-mc -triple thumbv8.1m.main -mattr=+mve -show-inst and feed it these instructions:

vadd.i16 q0, q1, q2
vpst
vaddt.i16 q0, q1, q2

then you get this output:

vadd.i16        q0, q1, q2      @ <MCInst #982 MVE_VADDi16
                                @  <MCOperand Reg:57>
                                @  <MCOperand Reg:58>
                                @  <MCOperand Reg:59>
                                @  <MCOperand Imm:0>
                                @  <MCOperand Reg:0>
                                @  <MCOperand Reg:0>
                                @  <MCOperand Reg:0>>
vpst                            @ <MCInst #1383 MVE_VPST
                                @  <MCOperand Imm:8>>
vaddt.i16       q0, q1, q2      @ <MCInst #982 MVE_VADDi16
                                @  <MCOperand Reg:57>
                                @  <MCOperand Reg:58>
                                @  <MCOperand Reg:59>
                                @  <MCOperand Imm:1>
                                @  <MCOperand Reg:56>
                                @  <MCOperand Reg:0>
                                @  <MCOperand Reg:57>>

The first three operands of each instruction are the obvious ones: 57 is q0, the output register, and 58 and 59 are q1 and q2, the explicit input registers. After that, the predicated VADD has an immediate 1 (indicating that it's predicated in "then" rather than "else" mode, i.e. writing the lanes corresponding to set bits of P0); then register 56 is the P0 predicate register; the empty Reg:0 parameter is only used for tail predication which we're not doing here; and finally Reg:57 is a second copy of q0, this time used as an input register. And the unpredicated version has 0,0,0,0 for those four operands.

[foad]

llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp

2506–2508

To model this in a MachineInstr in a way that shows the data flow, it's necessary to provide the previous value of the output register as an input, and then tie them to each other so that register allocation will make them the same physical register.

I'm pretty sure there are loads of examples like that in the AMDGPU backend, and we handle them in "convert" functions. But it's not my area of expertise and I have no idea how easy it would be to change the ARM backend over to that way of doing things.

[barannikov88]

llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp

2506–2508

It should be easy to add MII to CreateVPTPred and VCCOp and then use it in addVPTPredROperands.
But I don't think it should be done in this patch.

[foad]

Rebase

[barannikov88]

LGTM

llvm/utils/TableGen/InstrInfoEmitter.cpp

935

nit: reverse should be visible without llvm:: qualification.

llvm/include/llvm/MC/MCInstrInfo.h

 /// Interface to description of machine instruction set.
 class MCInstrInfo {
 public:
   using ComplexDeprecationPredicate = bool (*)(MCInst &,
                                                const MCSubtargetInfo &,
                                                std::string &);
 
 private:
-  const MCInstrDesc *Desc;          // Raw array to allow static init'n
+  const MCInstrDesc *LastDesc;      // Raw array to allow static init'n
   const unsigned *InstrNameIndices; // Array for name indices in InstrNameData
   const char *InstrNameData;        // Instruction name string pool
   // Subtarget feature that an instruction is deprecated on, if any
   // -1 implies this is not deprecated by any single feature. It may still be
   // deprecated due to a "complex" reason, below.
   const uint8_t *DeprecatedFeatures;
   // A complex method to determine if a certain instruction is deprecated or
   // not, and return the reason for deprecation.
   const ComplexDeprecationPredicate *ComplexDeprecationInfos;
   unsigned NumOpcodes;              // Number of entries in the desc array
 
 public:
   /// Initialize MCInstrInfo, called by TableGen auto-generated routines.
   /// *DO NOT USE*.
   void InitMCInstrInfo(const MCInstrDesc *D, const unsigned *NI, const char *ND,
                        const uint8_t *DF,
                        const ComplexDeprecationPredicate *CDI, unsigned NO) {
-    Desc = D;
+    LastDesc = D + NO - 1;
     InstrNameIndices = NI;
     InstrNameData = ND;
     DeprecatedFeatures = DF;
     ComplexDeprecationInfos = CDI;
     NumOpcodes = NO;
   }
 
   unsigned getNumOpcodes() const { return NumOpcodes; }
 
   /// Return the machine instruction descriptor that corresponds to the
   /// specified instruction opcode.
   const MCInstrDesc &get(unsigned Opcode) const {
     assert(Opcode < NumOpcodes && "Invalid opcode!");
-    return Desc[Opcode];
+    // The table is indexed backwards from the last entry.
+    return *(LastDesc - Opcode);
   }
 
   /// Returns the name for the instructions with the given opcode.
   StringRef getName(unsigned Opcode) const {
     assert(Opcode < NumOpcodes && "Invalid opcode!");
     return StringRef(&InstrNameData[InstrNameIndices[Opcode]]);
   }
 

llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp

   void addVPTPredROperands(MCInst &Inst, unsigned N) const {
     assert(N == 4 && "Invalid number of operands!");
     addVPTPredNOperands(Inst, N-1);
     unsigned RegNum;
     if (getVPTPred() == ARMVCC::None) {
       RegNum = 0;
     } else {
       unsigned NextOpIndex = Inst.getNumOperands();
-      const MCInstrDesc &MCID = ARMInsts[Inst.getOpcode()];
+      const MCInstrDesc &MCID =
+          ARMInsts[ARM::INSTRUCTION_LIST_END - 1 - Inst.getOpcode()];
       int TiedOp = MCID.getOperandConstraint(NextOpIndex, MCOI::TIED_TO);
       assert(TiedOp >= 0 &&
              "Inactive register in vpred_r is not tied to an output!");
       RegNum = Inst.getOperand(TiedOp).getReg();
     }
     Inst.addOperand(MCOperand::createReg(RegNum));
   }
 
   void addCoprocNumOperands(MCInst &Inst, unsigned N) const {

llvm/utils/TableGen/InstrInfoEmitter.cpp

void InstrInfoEmitter::run(raw_ostream &OS) {
   }
 
   OperandInfoMapTy OperandInfoIDs;
 
   // Emit all of the operand info records.
   Records.startTimer("Emit operand info");
   EmitOperandInfo(OS, OperandInfoIDs);
 
-  // Emit all of the MCInstrDesc records in their ENUM ordering.
-  //
+  // Emit all of the MCInstrDesc records in reverse ENUM ordering.
   Records.startTimer("Emit InstrDesc records");
   OS << "\nextern const MCInstrDesc " << TargetName << "Insts[] = {\n";
   ArrayRef<const CodeGenInstruction*> NumberedInstructions =
     Target.getInstructionsByEnumValue();
 
   SequenceToOffsetTable<std::string> InstrNames;
-  unsigned Num = 0;
-  for (const CodeGenInstruction *Inst : NumberedInstructions) {
+  unsigned Num = NumberedInstructions.size();
+  for (const CodeGenInstruction *Inst : reverse(NumberedInstructions)) {
     // Keep a list of the instruction names.
     InstrNames.add(std::string(Inst->TheDef->getName()));
     // Emit the record into the table.
-    emitRecord(*Inst, Num++, InstrInfo, EmittedLists, OperandInfoIDs, OS);
+    emitRecord(*Inst, --Num, InstrInfo, EmittedLists, OperandInfoIDs, OS);
   }
   OS << "};\n\n";
 
   // Emit the array of instruction names.
   Records.startTimer("Emit instruction names");
   InstrNames.layout();
   InstrNames.emitStringLiteralDef(OS, Twine("extern const char ") + TargetName +
                                           "InstrNameData[]");