[LLVMdev] Match operands

[Medic, Vladimir]

Hello Jim,

I have already done that, splitting for example ceil.w.s into 3 operands, this way:
Operands[0] = 'ceil' - mnemonic
Operands[1] = MCK__DOT_w
Operands[2] =  MCK__DOT_s

The problem is that after call to:
 // Search the table.
  std::pair<const MatchEntry*, const MatchEntry*> MnemonicRange =
    std::equal_range(MatchTable, MatchTable+277, Mnemonic, LessOpcode());

I have this:
 MnemonicRange.first = { Mips::CEIL_L_D64, 93 /* ceil */, Convert__Reg1_2__Reg1_3, { MCK__DOT_l, MCK__DOT_d, MCK_FGR64, MCK_FGR64 }, Feature_IsFP64bit, 0}
 MnemonicRange.second = { Mips::CEIL_L_S, 93 /* ceil */, Convert__Reg1_2__Reg1_3, { MCK__DOT_l, MCK__DOT_s, MCK_FGR64, MCK_FGR32 }, Feature_IsFP64bit, 0}

Thus, when the comparison is made the error is reported since actual operand is MCK__DOT_w and matcher expects MCK__DOT_l. So my question was how do I make the matcher take the entries with MCK__DOT_w, or if that is not possible, do I need to redefine the instruction so the '.w' or '.l' are not explicit operand types but rather a values for the same type?

Thanks

Vladimir
________________________________
From: Jim Grosbach [grosbach at apple.com]
Sent: Tuesday, May 22, 2012 6:48 PM
To: Medic, Vladimir
Cc: llvmdev at cs.uiuc.edu; Jovanovic, Petar
Subject: Re: [LLVMdev] Match operands


On May 22, 2012, at 8:05 AM, "Medic, Vladimir" <vmedic at mips.com<mailto:vmedic at mips.com>> wrote:

I'm trying to implement the standalone assembler for mips and I have encountered a problem in instruction operands matcher.
In mips instruction set there are math instructions with two format flags in the mnemonic, one for source and one for destination register.
For example ceil.w.s means both source and destination are F32 registers while ceil.l.d means both source and destination are F64 registers. Also, depending on the floating point unit configuration F64 may be either single 64 bit register or a pair of 32 bit registers. In the current implementation this instruction is defined as follows:

// Instructions that convert an FP value to 64-bit fixed point.
let Predicates = [IsFP64bit], DecoderNamespace = "Mips64" in
multiclass FFR1_L_M<bits<6> funct, string opstr> {
  def _S   : FFR1<funct, 16, opstr, "l.s", FGR64, FGR32>;
  def _D64 : FFR1<funct, 17, opstr, "l.d", FGR64, FGR64>;
}

// Instructions that convert an FP value to 32-bit fixed point.
multiclass FFR1_W_M<bits<6> funct, string opstr> {
  def _S   : FFR1<funct, 16, opstr, "w.s", FGR32, FGR32>;
  def _D32 : FFR1<funct, 17, opstr, "w.d", FGR32, AFGR64>,
             Requires<[NotFP64bit]>;
  def _D64 : FFR1<funct, 17, opstr, "w.d", FGR32, FGR64>,
             Requires<[IsFP64bit]> {
    let DecoderNamespace = "Mips64";
  }
}

defm CEIL_W  : FFR1_W_M<0xe, "ceil">;
defm CEIL_L  : FFR1_L_M<0xa, "ceil">;

When assembly matcher is generated these are created as five instructions, each having 'ceil' as mnemonic:

static const MatchEntry MatchTable[277] = {
.
.
.

 { Mips::CEIL_L_D64, 93 /* ceil */, Convert__Reg1_2__Reg1_3, { MCK__DOT_l, MCK__DOT_d, MCK_FGR64, MCK_FGR64 }, Feature_IsFP64bit, 0},
  { Mips::CEIL_L_S, 93 /* ceil */, Convert__Reg1_2__Reg1_3, { MCK__DOT_l, MCK__DOT_s, MCK_FGR64, MCK_FGR32 }, Feature_IsFP64bit, 0},
  { Mips::CEIL_W_D64, 93 /* ceil */, Convert__Reg1_2__Reg1_3, { MCK__DOT_w, MCK__DOT_d, MCK_FGR32, MCK_FGR64 }, Feature_IsFP64bit, 0},
  { Mips::CEIL_W_D32, 93 /* ceil */, Convert__Reg1_2__Reg1_3, { MCK__DOT_w, MCK__DOT_d, MCK_FGR32, MCK_AFGR64 }, Feature_NotFP64bit, 0},
  { Mips::CEIL_W_S, 93 /* ceil */, Convert__Reg1_2__Reg1_3, { MCK__DOT_w, MCK__DOT_s, MCK_FGR32, MCK_FGR32 }, 0, 0},
.

Note the "MCK_DOT_l" and "MCK_DOT_d" entries there. The matcher is expect those to be in the operand list as explicit token operands. Your parser will initially get the mnemonic, including those suffices as a single string, most likely. That will need to be manually split into its components so that the base mnemonic and the suffices are distinct for the matcher. ARM does similar things. I suggest looking there an example of how this might be done. Avert your eyes from some of the other horrible hackery in that function, though. ;)

-Jim

.
.
}

So, when the MatchInstructionImpl is called it seems to look for a pair of instructions that match the mnemonic:

 // Search the table.
  std::pair<const MatchEntry*, const MatchEntry*> MnemonicRange =
    std::equal_range(MatchTable, MatchTable+277, Mnemonic, LessOpcode());

The search will always end in first two entries ( Mips::CEIL_L_D64 and Mips::CEIL_L_S) thus reporting the 'invalid operand' error when ceil.w.x instruction is parsed.
Is there a way to direct this search somehow, maybe to use available features or we should change the definition of the instructions to have at least one format included in mnemonic?

Kind regards,
Vladimir
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120523/db00b890/attachment.html>