[LLVMdev] Summary of TableNextGen BOF
Sean Silva
chisophugis at gmail.com
Thu Dec 12 13:50:48 PST 2013
On Thu, Dec 12, 2013 at 4:50 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
>
> 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.
>
s/The say/The way/
-- Sean Silva
>
> 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/d2580c05/attachment.html>
More information about the llvm-dev
mailing list