[LLVMdev] tblgen internals

[Garrison Venn]

Hey Chris,

Ok, so I'm working on creating this trivial patch, for starters, but I'm trying to identify
a controlled unit test for tblgen. So all of the following test tblgen to various extents:

1) make
2) make unittests
3) make // with clang

and

4) make check // which I'm avoiding

Since I'm just starting to understand tblgen, I'm not comfortable with any of these
approaches (although I'm currently using make, with clang, and make unittests). I did not find 
any td files under unittests, and therefore am of the opinion such a direct unit test does 
not exist. Is this correct?

The end result is that I'll be submitting the patch to the group so someone else can
commit it, and I will do this when I find out what is going on with these new clang
enum comparison warnings.

Sorry for the noise for such an extremely trivial patch, but I'm rusty, and tblgen
is new to me. My current short term goal is to understand tblgen, by getting rid
of its global dependencies, and subsequently modify it to use a portable dlopen
like semantic so that one can plugin tblgen backends. Does this exist already?
Is anyone else interested in this? I'm interested in backends that accomplish 
results similar to those generated by clang's tblgen use. I think the options framework 
will work with a delayed option instantiation (through dlopen). I'm thinking one 
command line flag would trigger, the dlopen of the specified library, and subsequent 
flags would specify the action to take, each library having its own globally defined 
options. Could be some interference here from command line arguments not 
understood by the initial option action list, but I'm under the current impression that 
at least the global holding the option list (RegisteredOptionList) can be modified 
after the fact. I'll check further when I get there.

Now if only work would get out of the way. ;-)

Garrison

On Dec 9, 2010, at 18:32, Chris Lattner wrote:

> 
> On Dec 9, 2010, at 4:50 AM, Garrison Venn wrote:
> 
>> Is there a reason that RecordKeeper:: getAllDerivedDefinitions(...) implementation 
>> accesses the global Records instance instead of just referencing itself?
>> 
>> As far as I can tell from the usage:
>> 
>> 1) Records has the linkage as extern RecordKeeper Records in Record.h
>> 2) Is instantiated as a global in TableGen
>> 3) All llvm uses of getAllDerivedDefinitions SEEM to be manifested as a 
>> message to this global RecordKeeper
>> 
>> In short getAllDerivedDefinitions(...) sort of (non-static) treats RecordKeeper 
>> as a singleton but it is never accessed this way. It is always accessed via
>> the global: Records.
> 
> Hi Garrison,
> 
> There is no good reason.  This is one of many instances of tblgen just being poorly designed because noone gives it much love.  It would be great if you could send in or commit a patch to tidy this up, thanks!
> 
> -Chris
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101210/32530be3/attachment.html>