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

[Evan Cheng]

Hi David,

If I understand correctly, the reason you are pushing for all these extra abstraction features in TableGen language is to one day refactor SSE / AVX. The intention is to support future Intel ISA extensions which may extend AVX to vectors of arbitrary width. Am I understanding the purpose of these patches correctly?

Unfortunately I strongly disagree with the direction you are taking with this.

If we are to implement support for future Intel vector extension, we should add these instructions separately. I understand you are concerned about code duplication and would prefer to leverage what's already written. However, our experience has shown the extra levels of abstraction is always high level that makes TableGen debugging harder than it should. Adding more layers, as you are proposing, would just make it unnecessary difficult. I believe it will be counterproductive.

I have discussed this carefully with Chris and have decided this is not the direction where we want to go with TableGen. We would really appreciate that you would back out these changes.

Thanks,

Evan

On Oct 6, 2011, at 9:41 AM, David A. Greene wrote:

> 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
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits