Summary of TableNextGen BOF

Project Infrastructure LLVM Dev List Archives
1

Hello everyone.

I apologise for the sizeable delay in sending this.

The BoF was attended by quite a lot of people and there was general agreement that tablegen needs improvement in some shape of form. However there are many divergent ideas as to how to go about this improvement. Of course this is completely natural, tablegen being a versatile tool used by many different people for many different purposes.

Part of the attendees focused on missing features. Feature requests include:

  1. support for vector literals

  2. support for instruction/patterns with multiple outputs

  3. support complex transforms where types of input and output differ

  4. remove need of magic vars in complex patterns

  5. improve support for permutations of operands

  6. ability to implement DAG combines in tablegen

  7. auto detect/infer constraints

  8. add support or missing patterns and/or selectable insts

  9. extend tablegen unit tests to go beyond simple syntactic constructs

  10. automatically add MCDesc fields

  11. improve debug-ability

  12. improve error reporting

  13. auto-inversion for predicates

Someone in the room (I forgot the name, I’m sorry) said something which I found quite interesting, namely that he current state of tablegen is due to its quite rapid growth through the past years. Then point was raised that, probably, we will not be fixing anything by simply bolting on top further functionality.

My desire was to steer the discussion towards how to design tablegen as a proper domain specific language targeted at compiler construction. I think it was generally agreed that this is a distant goal worth pursuing and that the first steps is to first document what tablegen currently has.

The root cause for lack of documentation was identified as:

“People don’t feel authoritative enough to go ahead and write docs. Many community members are knowledgeable in small pieces, but don’t feel are qualified to author documentation”.

It was generally agreed that a way to solve this is to create a shared repository where everyone can commit any pieces of information they might have. We hope it will grow to a proper documentation for tablegen’s features. Once gotten there we would be in a much better position to decide how to further develop this tool.

Renato Golin was kind enough to offer to work on the documentation project. I myself intend to get involved too.

Best regards,
Mihai

2

Hi Mihail,

Thanks for the reminder, it fell out of my radar after I wrote a few
notes on that document.

I'll have a look this week and try to list its current uses, at least
so we know what we're dealing with.

cheers,
--renato

3

Hello everyone.

I apologise for the sizeable delay in sending this.

The BoF was attended by quite a lot of people and there was general
agreement that tablegen needs improvement in some shape of form. However
there are many divergent ideas as to how to go about this improvement. Of
course this is completely natural, tablegen being a versatile tool used by
many different people for many different purposes.

Part of the attendees focused on missing features. Feature requests
include:

   1.

   support for vector literals
   2.

   support for instruction/patterns with multiple outputs
   3.

   support complex transforms where types of input and output differ
   4.

   remove need of magic vars in complex patterns
   5.

   improve support for permutations of operands
   6.

   ability to implement DAG combines in tablegen
   7.

   auto detect/infer constraints
   8.

   add support or missing patterns and/or selectable insts
   9.

   extend tablegen unit tests to go beyond simple syntactic constructs
   10.

   automatically add MCDesc fields
   11.

   improve debug-ability
   12.

   improve error reporting
   13. auto-inversion for predicates

Someone in the room (I forgot the name, I'm sorry) said something which I
found quite interesting, namely that he current state of tablegen is due to
its quite rapid growth through the past years. Then point was raised that,
probably, we will not be fixing anything by simply bolting on top further
functionality.

My desire was to steer the discussion towards how to design tablegen as a
proper domain specific language targeted at compiler construction. I think
it was generally agreed that this is a distant goal worth pursuing and that
the first steps is to first document what tablegen currently has.

The root cause for lack of documentation was identified as:

*"People don't feel authoritative enough to go ahead and write docs. Many
community members are knowledgeable in small pieces, but don’t feel are
qualified to author documentation".*

The say I got http://llvm.org/docs/TableGen/LangRef.html up and running is
by going through the source code of the parser and lexer line by line. It
still has a long way to go, because it only barely talks about the
semantics of the constructs; it's mostly just a grammar at the moment.

I was only able to do that line-by-line walkthrough after getting some
familiarity with the code. I urge all people who have some familiarity (not
even very much) with particular parts of tablegen, in particular the
emitters in utils/TableGen, to try to do a "sprint" walking through the
code to build up a skeleton description, like I did for
docs/TableGen/LangRef.rst. <
http://llvm.org/docs/SphinxQuickstartTemplate.html&gt; has everything you need
to get up and running with writing docs.

It was generally agreed that a way to solve this is to create a shared
repository where everyone can commit any pieces of information they might
have. We hope it will grow to a proper documentation for tablegen's
features. Once gotten there we would be in a much better position to decide
how to further develop this tool.

Once we have some initial "skeletons" for describing various parts,
hopefully people will be able to find a place to describe whatever small
piece of "local" knowledge of TableGen that that they may have, to help
piece together the "global" picture.

-- Sean Silva

4

Hello everyone.

I apologise for the sizeable delay in sending this.

The BoF was attended by quite a lot of people and there was general
agreement that tablegen needs improvement in some shape of form. However
there are many divergent ideas as to how to go about this improvement. Of
course this is completely natural, tablegen being a versatile tool used by
many different people for many different purposes.

Part of the attendees focused on missing features. Feature requests
include:

   1.

   support for vector literals
   2.

   support for instruction/patterns with multiple outputs
   3.

   support complex transforms where types of input and output differ
   4.

   remove need of magic vars in complex patterns
   5.

   improve support for permutations of operands
   6.

   ability to implement DAG combines in tablegen
   7.

   auto detect/infer constraints
   8.

   add support or missing patterns and/or selectable insts
   9.

   extend tablegen unit tests to go beyond simple syntactic constructs
   10.

   automatically add MCDesc fields
   11.

   improve debug-ability
   12.

   improve error reporting
   13. auto-inversion for predicates

Someone in the room (I forgot the name, I'm sorry) said something which I
found quite interesting, namely that he current state of tablegen is due to
its quite rapid growth through the past years. Then point was raised that,
probably, we will not be fixing anything by simply bolting on top further
functionality.

My desire was to steer the discussion towards how to design tablegen as a
proper domain specific language targeted at compiler construction. I think
it was generally agreed that this is a distant goal worth pursuing and that
the first steps is to first document what tablegen currently has.

The root cause for lack of documentation was identified as:

*"People don't feel authoritative enough to go ahead and write docs. Many
community members are knowledgeable in small pieces, but don’t feel are
qualified to author documentation".*

The say I got http://llvm.org/docs/TableGen/LangRef.html up and running
is by going through the source code of the parser and lexer line by line.
It still has a long way to go, because it only barely talks about the
semantics of the constructs; it's mostly just a grammar at the moment.

s/The say/The way/

-- Sean Silva