On Tue, Mar 18, 2014 at 9:03 AM, Renato Golin <renato.golin at linaro.org>
wrote:> On 18 March 2014 12:54, Aaron Ballman <aaron at aaronballman.com>
wrote:
>> Would it also make sense to include the clang usages of tablegen
>> somewhere in #1, and then perhaps have #2.5 about clang usages (not
>> volunteering you for that work btw)? Diagnostics and attributes make
>> heavy use of tablegen in clang, for instance.
>
> I meant to ask about this... Clang has a huge list of back-ends and
> they seem extremely similar to each other. Is there any reason why
> this is necessary, is this some deficiency in how the TableGen engine
> runs, or was it just the simplest way to add functionality?
Some of it has to do with layering. For instance, many of the
attribute tablegen backends exist because they generate .inc files for
the lexer, the parser, sema, etc.
Some of it has to do with what's being generated -- sometimes it's a
.inc file with complete implementations of functionality, other times
it's a .inc file with just some StringSwitch .Case statements, etc.
Some of it is likely simple misunderstanding of what can be done. :-)
I would love to consolidate some more of the clang tablegen backends
(I already did this with the StringSwitch cases where possible).
> I agree it'd be good to have both LLVM and Clang usages.
Awesome! And btw, since I kind of failed to mention it before: your
plan looks good to me, and thanks for working on it!
~Aaron