[PATCH] D62669: [ARM] Set up infrastructure for MVE vector instructions.

Simon Tatham via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 11 07:59:07 PDT 2019


simon_tatham marked an inline comment as done.
simon_tatham added inline comments.


================
Comment at: llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:2183
+      unsigned NextOpIndex = Inst.getNumOperands();
+      const MCInstrDesc &MCID = ARMInsts[Inst.getOpcode()];
+      int TiedOp = MCID.getOperandConstraint(NextOpIndex, MCOI::TIED_TO);
----------------
dmgreen wrote:
> I think this should be using MII.get(Inst.getOpcode()), if it can.
Unfortunately, that's rather fiddly, because the context here is that we're in a method of `ARMOperand`, which doesn't have an `MCInstrInfo` conveniently accessible that I can find – the `ARMAsmParser` as a whole is given one at construction time, but it's not passed through to `ARMOperand`.

I wondered about changing the prototype of this `addVPTPredROperands` method so that it received the `MCInstrDesc` from its caller, and then //that// could look it up in the ambient `MCInstrInfo`. But the caller is the tablegenerated AsmMatcher, and that has hard-coded function call code for all the RenderMethods which expects them to conform to the same API, so that would be a huge piece of plumbing to change.

I think leaving it as it is is safe from a modules perspective. We're referring directly to the `llvm::ARMInsts` array, which is defined in the `LLVMARMDesc` library. But that library also defines the `llvm::ARMMCRegisterClasses` array, which we refer to constantly in this same source file. So anyone linking against this module must surely also have `LLVMARMDesc` available, or else they'd already have had a link error.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62669/new/

https://reviews.llvm.org/D62669





More information about the llvm-commits mailing list