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>
On 10 December 2013 11:38, Mihail Popa <mihail.popa at gmail.com> wrote:> Renato Golin was kind enough to offer to work on the documentation project. > I myself intend to get involved too.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
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>
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>
Maybe Matching Threads
- [LLVMdev] Summary of TableNextGen BOF
- [LLVMdev] Instructions with overlapping encodings that are disambiguated by field comparisons
- [LLVMdev] [PATCH] Two patches related to ARM TrustZone support
- [LLVMdev] Trap instruction for ARMv7 and Thumb
- GlobalISel BoF follow-up