[LLVMdev] Summary of TableNextGen BOF

Mihail Popa mihail.popa at gmail.com
Tue Dec 10 03:38:39 PST 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131210/bb9592c0/attachment.html>


More information about the llvm-dev mailing list