[llvm-commits] [llvm] r141230 - /llvm/trunk/include/llvm/TableGen/Record.h

David A. Greene greened at obbligato.org
Thu Oct 6 09:41:03 PDT 2011


Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:

> I liked Che-Liang Chiou's for loops better: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-August/042669.html

Yes, I think that could work.  One thing I think could use some
tweaking:

(Equivalent TableGen code with a for-loop)
----------------------------------------
multiclass PTX_FLOAT_4OP<string opcstr, SDNode opnode1, SDNode opnode2> {
  for nbit         = [32, 32, 64, 64],
      op_suffix    = [r, i, r, i],
      op_type      = [RegF32, f32imm, RegF64, f64imm],
      op_node_type = [RegF32, fpimm, RegF64, fpimm] in {
    def rr#op_suffix#nbit
      : InstPTX<(outs RegF#nbit:$d),
                (ins RegF#nbit:$a, RegF#nbit:$b, #op_type:$c),
                !strconcat(opcstr, ".f#nbit\t$d, $a, $b, $c"),
                [(set RegF#nbit:$d,
                   (opnode2 (opnode1 RegF#nbit:$a, RegF#nbit:$b),
                            #op_node_type:$c))]>;
  }
}

It looks as if this does a "zip iterator" on the various lists.  I would
also like the ability do generate the "cross product."  Nested for loops
would allow that.  Is nesting part of the proposal?

>From my very cursory glance, this looks like a good improvement.  I
don't like the idea of it being a separate preprocessing phase however,
because I can imagine the utility of having it interoperate with other
TableGen constructs.

                           -Dave



More information about the llvm-commits mailing list