[PATCH] [Tablegen] Attempt to add support for patterns containing nodes with multiple results.

hfinkel at anl.gov hfinkel at anl.gov
Wed Mar 18 05:56:30 PDT 2015

In http://reviews.llvm.org/D8373#142510, @tstellarAMD wrote:

> The second output on those R600 instructions is just there to reserve a temp register to make it easier to lower the instruction later on.  I think this patch should be OK.

Alright, I see what you mean, you have this:

  def SI_INDIRECT_SRC : InstSI <
    (outs VGPR_32:$dst, SReg_64:$temp),
    (ins unknown:$src, VSrc_32:$idx, i32imm:$off),
    "si_indirect_src $dst, $temp, $src, $idx, $off",

and so when you use this:

  // 1. Extract with offset
  def : Pat<
    (vector_extract vt:$vec, (add i32:$idx, imm:$off)),
    (eltvt (SI_INDIRECT_SRC (IMPLICIT_DEF), $vec, $idx, imm:$off))

the pattern generates the IMPLICIT_DEF as the output operand somehow (even though it is written as an input operand), and you get the scratch register that you need.

Would [Any, Any] make sense here too?

Craig, this is indeed a use case we need to support: having a pseudo-instruction with a 'scratch register' output definition. However, it does raise the question that, if we're going to support pattern matching instructions with multiple output operands (which is the point here), what should we do if the input pattern does not itself have multiple output operands?

In short, I don't understand your any_i1 solution. It does not help to match the type of vector_insert, etc., and SI_INDIRECT_SRC, etc. already have multiple output operands. The type of the second output operand might have an ambiguous type, but why does that matter if we're not matching against it? Forcing the user to choose a type that is sure to be ignored / irrelevant seems confusing.



More information about the llvm-commits mailing list