[LLVMdev] tblgen internals

[Garrison Venn]

Thanks Chris,

I can't really comment on the direction because my understanding is still syntax based. I 
don't have a comfortable grasp yet of tblgen beyond the llvm doc, how the results are used
in Clang--I'm still very ignorant of llvm backend generation (the real purpose), and the code
calling paths. When I made the mod to Record, adding the RecordKeeper pointer, it did not
even dawn on me that it was a issue. I was under the impression that the number of
records created was ~O(10^2), and that they were not used inline to the rest of the system.

Your comment though made me think that my assumptions were incorrect. So this has to be 
your call.

I do have one opinion though. I believe that tblgen doc needs to be completed, or at least
helped along, and thus thought that allowing one to create their own tblgen backend would
go some ways to help with its understanding. A couple of developer's who use it ,indicated
to me that there was there was still an aura of magic (my words), to how certain tblgen backends 
interpreted a record's values. Of course this is more of a comment on these backend emitters 
than on tblgen's core which is pretty straight forward. Regardless one way to allow developer's
to create their own backends for play, or other purposes would be to create some sort of 
plugin architecture. And one way to implement such an architecture is via dlopen or in llvm
portable parlance: llvm::sys::DynamicLibrary::LoadLibraryPermanently(...) (looking a PluginLoader
now), triggered by an option to tblgen. I personally am exploring such a mechanism for
clang AST translation purposes--tblgen generated code probably used in conjunction with 
clang::RecursiveASTVisitor<...>.

Is this kind of mod (adding plugins), viable for tblgen?

And tblgen is cool, all we have to do is add an evaluation model, and we have ... :-) Some
of my newly acquainted anti turning complete compatriots will now skewer me. :-)

Anyway thanks again for the time and your tolerance for my verbosity.

Garrison

On Dec 14, 2010, at 23:53, Chris Lattner wrote:

> On Dec 12, 2010, at 8:12 PM, Garrison Venn wrote:
> 
>>> I believe I caught most of the syntax style issues with the attached patch. It only contains
>>> these style changes.
> 
> Thanks! I applied your followup patch in r121837.
> 
>> Concerning the RecordKeeper reference in Record. Would you prefer to partially go
>> back to a more limited constrained version of a global. Since we are not threaded anyway,
>> we could turn the reference into a singleton for the duration of an initial parse and use session.
>> The concept would be to instead make the reference a static pointer, make RecordKeeper
>> a friend of Record, and add RecordKeeper::resetSession(void). resetSession would set
>> the static pointer to itself. Asserts would also have to be added to the methods which needed
>> a Record to have a non-NULL RecordKeeper pointer. Although we would in effect still be
>> using a global, we would be allowing it to be controlled while simultaneously removing the
>> sizeof(RecordKeeper*) number of bytes from Record instances. Offsets into a another say 
>> SmallVector instance could also be attempted, but this seems messy to me. 
> 
> I prefer to make RecordKeeper not a global.  This leaves us with three options: 1) keep the ivar reference, 2) pass the reference into any method that (transitively) needs the recordkeeper. 3) do #2, but refactor code so that it doesn't have to be passed around as much.
> 
> I honestly don't know what is best, if you think the current solution is good enough, lets stay with it.  Tblgen isn't exactly a paragon of high performance or low memory use anyway :)
> 
> Thanks Garrison!
> 
> -Chris