[LLVMdev] Nested multiclass/defm declarations?

Andreas Fredriksson deplinenoise at gmail.com
Thu Sep 13 06:36:26 PDT 2007


Hi list,
I'm toying with the idea of writing a m680x0 backend for LLVM, and the
address modes of this chip are bewildering, to say the least. Here's a
rough list off wikipedia for reference:

    * Register direct
          o data register, e.g. "D0"
          o address register, e.g. "A6"

    * Register indirect
          o Simple address, e.g. (A0)
          o Address with post-increment, e.g. (A0)+
          o Address with pre-decrement, e.g. -(A0)
          o Address with a 16-bit signed offset, e.g. 16(A0)

    * Register indirect with an Index
          o 8-bit signed offset, e.g. 8(A0, D0) or 8(A0, A1)

    * PC (program counter) relative with displacement
          o 16-bit signed offset, e.g. 16(PC).
          o 8-bit signed offset with index, e.g. 8(PC, D2)

    * Absolute memory location

    * Immediate mode
          o Stored in the instruction, e.g. "#400".

Quite a few instructions support arbitrary choices of EA (effective
addressing) modes for both operands, giving an explosion of
permutations (11 * 11 !!). I thought about using a nested multiclass
declaration to resolve this, as in

multiclass EAPermuteRhs<dag lhs_oper, string asmstr> {
  def _dx : I<(outs DataRegister:$dst), lhs_oper, ..... > ;
  def _ax : I<(outs AddressRegister:$dst), lhs_oper, ..... > ;
  def _ax_postincrement : I<(outs AddressRegister:$dst), lhs_oper, ..... > ;
  // And many more
}

multiclass EAPermute<string asmstr> {
  defm _dx : EAPermuteRhs<(ins DataRegister:$src), asmstr> ;
  defm _ax : EAPermuteRhs<(ins AddressRegister:$src), asmstr> ;
  // etc
}

This would allow me to generate the complete host of permutations for
say, MOVE, with the declaration:

defm MOVE : EAPermute<"move"> ;

However, tablegen doesn't appear to grok defm declarations within
multiclass declaration, so that was a showstopper.

Does this make sense, or is there another way to achieve the same effect?

Thanks,
// Andreas



More information about the llvm-dev mailing list