[LLVMdev] Enhancing TableGen

[David A. Greene]

Jakob Stoklund Olesen <jolesen at apple.com> writes:

> 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.

How is that so?

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

What do you mean by that?  They came from the .td file, right?  I'm
really not understanding what you need here.

You still haven't answered the question.  What properties are most
important to make plain?

>> 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.

It is NOT no benefit.  The benefuit is writing patterns once and getting
them to work everywhere.  When we find a bug we fix it in once place.

If that's not important to the LLVM community, that's fine.  But don't
claim there is no benefit.

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

I'm not sure what you mean.  The Intel/AMD manuals are the reference.
Anything else is going to be buggy.  The .td files are an implementation
of that reference.

> Compressing them with clever abstractions is contrary to that.

It doesn't have to be.

It's clear that the LLVM leadership will not allow the sort of
improvements I would like to see to ease maintenenace.  That's ok, I'll
live with it.  But it's very unfortunate given the experience I have had
working with the x86 SIMD implementation.

                              -Dave