[LLVMdev] Enhancing TableGen

Jakob Stoklund Olesen jolesen at apple.com
Fri Oct 7 16:24:27 PDT 2011

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.


More information about the llvm-dev mailing list