[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