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

Zhan Jun Liau via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 3 14:46:31 PDT 2016


zhanjunl added a comment.

In https://reviews.llvm.org/D21809#504840, @uweigand wrote:

> Well, the mnemonic would be just ".insn", and "e" would be the first operand, decoded as fixed string.  If you simply use ".insn e, ..." as an AsmParser pattern, you should see something like this in the generated SystemZGenAsmMatcher.inc file:
>
> static const MatchEntry MatchTable0[] = {
>
>   { 0 /* .insn */, SystemZ::AsmInsnE, Convert__U16Imm1_1, 0, { MCK_e, MCK_U16Imm }, },
>   { 0 /* .insn */, SystemZ::AsmInsnRI, Convert__U32Imm1_1__AnyGRFP1_2__S16Imm1_3, 0, { MCK_ri, MCK_U32Imm, MCK_AnyGRFP, MCK_S16Imm }, },
>   { 0 /* .insn */, SystemZ::AsmInsnRIE, Convert__U48Imm1_1__AnyGRFP1_2__AnyGRFP1_3__PCRel161_4, 0, { MCK_rie, MCK_U48Imm, MCK_AnyGRFP, MCK_AnyGRFP, MCK_PCRel16 }, },
>   
>
> where the MCK_e, MCK_ri etc are matched as string constants via matchTokenString.


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.

  static const OperandMatchEntry OperandMatchTable[2076] = {
    { 0, 0 /* .insn */, MCK_BDAddr64Disp12, 4 /* 2 */ },
    { 0, 0 /* .insn */, MCK_AnyGRFP, 4 /* 2 */ },
    { 0, 0 /* .insn */, MCK_PCRel32, 8 /* 3 */ },
    { 0, 0 /* .insn */, MCK_AnyGRFP, 12 /* 2, 3 */ },

The code for parsing operands goes through that table and for every entry that matches the mnemonic, will try to parse the current operand based on the current entry. So for example,

  .insn ri,0xa7080000,%r1,1

Based on the table, operand #2 could be a PCRel32 or a register, or an immediate. The parser will try to parse operand #2 as a PC-rel first because it's the first entry, which means that "1" could be parsed as a pc-rel operand, when it should have been an immediate. The same goes for immediate vs register, immediate vs address, etc. I'm not sure how to pick the right operand parser routine, and I'm not sure it's even possible using ParseInstruction based on the way the table is set up.

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.


https://reviews.llvm.org/D21809





More information about the llvm-commits mailing list