[TableGen][AsmParser][MC] isAsmParserOnly flag in class Instruction

Hi all,
I’m working on llvm assembler support for Mips and for a while I’m trying to solve a problem regarding complex macro instructions. As mips assembler supports macro instructions that can develop to more then one real instruction depending on the operand type(usually two or three) we can’t use InstAlias to exploit tableGen generated code. Currently we expand these in MipsAsmParser in a post processing methods, but I would like to at least be able to easily identify them, and if possible call some method that handles this to avoid giant switch/case structure in method that processes them. I have seen that in Target.td file in class instruction there is a flag isAsmParserOnly which could be used to mark these macros:
// Is this instruction a pseudo instruction for use by the assembler parser.
bit isAsmParserOnly = 0;

but, as far as I can tell, this flag is not available to the AsmParser nor it can be accessed via MCInstrDesc class that we import as externally defined. In fact, the only thing it is used for is to avoid generating codeGen info for these instructions in tableGen. So, I was wandering if there is a plan to use this flag in asmMatcher or at least make it available in AsmParser?

Kind regards

Vladimir Medic

Hi Vladimir,

ARM does similar things for complex assembly pseudos. Have a look at the definition and use of AsmPseudoInst in the ARM backend. They’re not typically expanding to multiple “real” instructions, but that’s an implementation detail, not a constraint.


Hi Jim,
I did look at the ARMAsmParser and it seems to me that it is using a switch/case construct to change the opcode and the operands, but this construct may become too large eventually. I was wondering if it is possible to use isAsmParser only flag to call dedicated methods, like dedicated parsers for AsmOperands.



We could probably do something like that. I don’t think that flag is the right hook for it, necessarily, but the concept is reasonable. That said, I don’t know that we need it right now. It would just auto-generate a switch/case for you and call dedicated methods for doing the expansion. Why not go ahead and write those methods and manually write the switch/case for now, then if/when it gets too large (for some hand wavy notion of “too large”), we can refactor to auto generate the switch and all of the workhorse functions will just continue to work as-is.