[PATCH] D53816: [TableGen:AsmWriter] Cope with consecutive tied operands.

[Simon Tatham via Phabricator via llvm-commits]

simon_tatham added a comment.

Could I give this a gentle ping, please?

If you'd like a concrete example of how it could affect a real back end, I've just come up with a trivial example using an existing Thumb instruction. Suppose you added this declaration to the bottom of `lib/Target/ARM/ARMInstrThumb2.td`:

  def DemoAddSquareAlias : t2InstAlias<"demoaddsquare${p} $d1, $d2, $s", (t2UMLAL rGPR:$d1, rGPR:$d2, rGPR:$s, rGPR:$s, pred:$p), 1>;

which defines "demoaddsquare d1,d2,s" to add s^2 to the 64-bit value in registers d1,d2, by expanding to a special case of UMLAL in which both source registers are the same, and sets the priority so that the alias should be used in disassembly.

Without this patch, the following command (in which the encoding is for `umlal r0, r1, r2, r2`):

  llvm-mc -triple thumbv7a -disassemble <<<"[0xe2,0xfb,0x02,0x01]"

recognises the instruction as a case of this demo alias, and gets as far as printing the alias //mnemonic// (`demoaddsquare`), but then fails an assertion:

  MCInst.h:77: int64_t llvm::MCOperand::getImm() const: Assertion `isImm() && "This is not an immediate"' failed.

But with the patch, that disassembly succeeds, and prints `demoaddsquare r0, r1, r2` just as it should.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D53816