[PATCH] D91704: [llvm-mca] Fix processing thumb instruction set

Dave Green via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 23 04:22:06 PST 2020


dmgreen added inline comments.


================
Comment at: llvm/lib/MCA/InstrBuilder.cpp:251
+bool InstrBuilder::isThumb1Inst(const MCInstrDesc &MCDesc) const {
+  static const unsigned ThumbFrm = 25 << 7; // ARMII::ThumbFrm
+  return STI.getTargetTriple().isThumb() &&
----------------
evgeny777 wrote:
> dmgreen wrote:
> > Please don't rely on ThumbFrm, a lot of those flags are legacy and should be removed.
> > 
> > I was hoping that this wouldn't have to say "if (thumb)" anywhere, even if the instructions are a little odd. Can it check the position of the optional def instead? So it detects instructions like this, without having to be target dependent.
> > Can it check the position of the optional def instead
> 
> Do you have an idea how to do this? One has to distinguish
> a) Instruction that writes to single register and optionally modifies CPSR (Thumb1)
> b) Instruction that writes to two registers and optionally modifies CPSR (ARM, Thumb2)
Can we just check which operand it is? Use MCDesc.OpInfo[i].isOptionalDef()? Can we just skip it in that case?


================
Comment at: llvm/lib/MCA/InstrBuilder.cpp:310-311
+
+  unsigned NumVariadicOps =
+      MCDesc.isVariadic() ? MCI.getNumOperands() - MCDesc.getNumOperands() : 0;
   ID.Writes.resize(TotalDefs + NumVariadicOps);
----------------
evgeny777 wrote:
> dmgreen wrote:
> > evgeny777 wrote:
> > > andreadb wrote:
> > > > > Some Thumb instructions (like tMOVSr) have less number of operands in their MCInstrDesc than MCInst.getNumOperands()
> > > > 
> > > > Could you elaborate this a bit more? It is a bit concerning that there is a mismatch in the number of operands. What are exactly these extra operands?
> > > > 
> > > > I need to understand if the assumptions made by this algorithm are still valid. Specifically, I need to understand if all of the assumptions described in the comment starting at line 256 are still valid. Can we still guarantee that "Uses always start at index #(MCDesc.getNumDefs())"? Is the order of writes still preserved?
> > > > Could you elaborate this a bit more? It is a bit concerning that there is a mismatch in the number of operands. What are exactly these extra operands?
> > > 
> > > If you look at tMOVSr you'll find out that it has 4 operands. For instance `movs r2, r3` is assembled to:
> > > ```
> > >  <MCInst #4275 tMOVSr <MCOperand Reg:74> <MCOperand Reg:75> <MCOperand Imm:14> <MCOperand Reg:0>>
> > > ```
> > > The last two args are, I beleive, built-in ARMCC::AL predicate
> > > 
> > > However tMOVSr definition lists only 2 arguments:
> > > ```
> > > def tMOVSr {  // InstructionEncoding
> > > // ...
> > >   dag OutOperandList = (outs tGPR:$Rd);
> > >   dag InOperandList = (ins tGPR:$Rm);
> > > // ...
> > > }
> > > ```
> > > InstrBuilder incorrectly treats tMOVSr as variadic, because 4 != 2
> > > 
> > This one sounds like a bug to me. Maybe in the AsmParsing? MOVS can't be used in IT blocks, so probably shouldn't use predicated. If you look at PR36658.mir, it looks like ` $r1 = tMOVSr $r0, implicit-def dead $cpsr`
> > This one sounds like a bug to me
> May be. I tried to address this in disassembler, but it broke a lot of stuff.
> 
> Here is a piece from ARMDisassembler.cpp
> ```
>   // A few instructions actually have predicates encoded in them.  Don't
>   // try to overwrite it if we're seeing one of those.
>   switch (MI.getOpcode()) {
>     case ARM::tBcc:
>     case ARM::t2Bcc:
>     case ARM::tCBZ:
>     case ARM::tCBNZ:
>     case ARM::tCPS:
>     case ARM::t2CPS3p:
>     case ARM::t2CPS2p:
>     case ARM::t2CPS1p:
>     case ARM::t2CSEL:
>     case ARM::t2CSINC:
>     case ARM::t2CSINV:
>     case ARM::t2CSNEG:
>     case ARM::tMOVSr:
>     case ARM::tSETEND:
> ```
It's possibly this code from ARMAsmParser:
```
      TmpInst.setOpcode(Inst.getOperand(4).getReg() ? ARM::tMOVSr : ARM::tMOVr);
      TmpInst.addOperand(Inst.getOperand(0));
      TmpInst.addOperand(Inst.getOperand(1));
      TmpInst.addOperand(Inst.getOperand(2));
      TmpInst.addOperand(Inst.getOperand(3));
```


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

https://reviews.llvm.org/D91704



More information about the llvm-commits mailing list