[LLVMdev] Enhancing TableGen

[Jakob Stoklund Olesen]

On Oct 7, 2011, at 2:23 PM, David A. Greene wrote:

>> As repeated many times on this thread, the most common operation that
>> a .td file must support is looking up an instruction and figuring out
>> what its properties are and where they came from.
> 
> Ok.  What properties are most important to look up?  I have found it
> really easy to just run "tblgen X86.td" and look at the output.  That's
> really the canonical definition, right?

In other words, .td files are write-only.  This is not acceptable.

It also doesn't answer '...and where they came from'.

> This could be mitigated somewhat by doing something like this:
> 
> class binary_pattern<string opcstr, string type> {
>  string pattern = !strconcat(opcstr, "$r."#type#"\t$d, $a, $b");
> }
> 
> multiclass PTX_FLOAT_3OP<string opcstr> {
>  def rr32 : InstPTX<(outs RegF32:$d),
>                     (ins RndMode:$r, RegF32:$a, RegF32:$b),
>                     binary_pattern<opcstrm "f32">.pattern, []>;
>  def ri32 : InstPTX<(outs RegF32:$d),
>                     (ins RndMode:$r, RegF32:$a, f32imm:$b),
>                     binary_pattern<opcstrm "f32">.pattern, []>;
>  def rr64 : InstPTX<(outs RegF64:$d),
>                     (ins RndMode:$r, RegF64:$a, RegF64:$b),
>                     binary_pattern<opcstrm "f64">.pattern, []>;
>  def ri64 : InstPTX<(outs RegF64:$d),
>                     (ins RndMode:$r, RegF64:$a, f64imm:$b),
>                     binary_pattern<opcstrm "f64">.pattern, []>;
> }
> 
> Would something like that be acceptable?

You are adding complexity for no benefit.  Now I have to look up the definition of InstPTX AND binary_pattern?  This is not helping.

Please focus your efforts on making .td files easy to use as an instruction reference.

Compressing them with clever abstractions is contrary to that.

/jakob