[LLVMdev] Summary of TableNextGen BOF

[Sean Silva]

On Tue, Dec 10, 2013 at 6:38 AM, Mihail Popa <mihail.popa at gmail.com> wrote:

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


>
> Renato Golin was kind enough to offer to work on the documentation
> project. I myself intend to get involved too.
>
> Best regards,
> Mihai
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131212/a92cd26b/attachment.html>