[PATCH] D42293: [TableGen][AsmMatcherEmitter] Fix tied-constraint checking for InstAliases

[Sander de Smalen via Phabricator via llvm-commits]

sdesmalen added a comment.

In https://reviews.llvm.org/D42293#981862, @olista01 wrote:

> I was looking at your original version of this the other day to work out if it could be used to do 3-operand aliases of 2-operand Thumb1 instructions, and this (adding support for aliases) looks like it's what we would need for that.


That's great to hear!

> Why do you need to modify the conversion to MCInst?

Well, this patch doesn't change the actual conversion to MCInst, it just encodes more information into the conversion-function by using an indirection through the 'TiedAsmOperandTable'. It will still create the MCInst in the same way as it did before.

> There is still a parsed operand for every MCInst operand, so can the existing conversion function not handle this already?

Yes, however the existing conversion function does not encode which parsed operands correspond to each other and rather just tells 'Copy operand X' from the list of result operands  (which is not the same as the list of parsed operands). This patch adds that extra bit of information to the conversion function, so now it can just say that "parsed operand Y" and "parsed operand Z" should match (that both result in "result operand X").  I hope my explanation/terminology makes some sense :)

> Thinking about how to integrate this with the new diagnostics used in the ARM assembler, I think it might be better to check tied operands at the same time as we check the operand classes. In fact, the tied-operand check might be able to replace the operand class check.

That might be possible, but I worry that it might lead to unmatched instructions and/or vague error messages if the register-operands don't match up. At the moment it just tries to match the whole instruction based on the operand classes, and then checks that the operands should be the same, already knowing they are of the right operand class, so we already know the instruction should otherwise match. What would be the benefit of doing it during matching of the operand classes?


https://reviews.llvm.org/D42293