[PATCH] D21809: [SystemZ] Add support for the .insn directive.

[Ulrich Weigand via llvm-commits]

uweigand added a comment.

In https://reviews.llvm.org/D21809#505251, @zhanjunl wrote:

> Hmm, that table is used for matching the instruction after the instruction has been parsed. ParseInstruction uses the OperandMatchTable for parsing operands, which looks like this if I use the ".insn e,..." forms.


Ah, I completely forgot about this two-step process.  Yes, this is quite annyoing and would not work as I thought.

> Unless there's something I'm missing, the only solution I could come up with is to write a custom parser that parses everything for the .insn directive, and use MatchTable0 to make sure that the operands are correct, but there would be some overlap in code with the other custom parser routines.


I don't see any really clever option here either.  Probably the best way forward would be to go back to a custom //operand parsing//, based on a table similar to your original approach, where for each format you have a list of operand parser routines you call in sequence to collect all the operands.  These routines should be the same that would also be called from the auto-generated operand parser, so e.g. for InsnRIL you'd call parseAnyGRFP and then  parsePCRel32.

For //code generation// you'd then use the Insn* patterns (marked isCodeGenOnly) of your current approach.

This is still a bit annoying since the operand info is now still duplicated between the patterns and your special table.  But I guess that's the best we can for now without major reworks to TableGen.


https://reviews.llvm.org/D21809