[LLVMdev] TableGen: Requesting feedback for "TGContext"

[Chris Lattner]

It won't cause a negative effect, go for it!  Dynamic_cast is realllly slow compared to dyn_cast, it is worth the memory.

-Chris

On Oct 3, 2012, at 9:39 PM, Sean Silva <silvas at purdue.edu> wrote:

> Thanks for the feedback!
> 
>>> Does anybody have anything else they think should go into TGContext or
>>> any other responsibilities it should have? Or any feedback about the
>>> idea in general?
>> 
>> All memory allocations should go into its bump pointer, RecordKeeper should as well.  Any other global state that exist should also.
> 
> Sounds good.
> 
>>> I'm also hoping that this change should loosen up some of the
>>> calcification that has accumulated on TableGen and get the ball
>>> rolling for transitioning dynamic_cast<> to dyn_cast<> and eliminating
>>> exceptions, along with general improvements in reliability and
>>> performance. Along the way I'm also hoping to pull together proper
>>> reference documentation for the language as it stands right now.
>> 
>> This would be really really great.  Just moving off dynamic_cast is a quite mechanical change that should be straight-forward to do.
> 
> Indeed, the transition to LLVM-style RTTI it is mostly mechanical. The
> thing that has been keeping me is that adding the discriminator---as
> far as I can tell---will increase sizeof() by a pointer due to
> alignment, and I've been too lazy to collect any information about
> whether this will have a detectable performance cost overall.
> 
> --Sean Silva
> 
> On Wed, Oct 3, 2012 at 11:51 PM, Chris Lattner <sabre at nondot.org> wrote:
>> 
>> On Oct 3, 2012, at 7:07 PM, Sean Silva <silvas at purdue.edu> wrote:
>> 
>>> Hi all, I'm sure that the last thing that you want to think about is
>>> TableGen's guts, but I'm pursuing a course in bringing TableGen up to
>>> snuff with the rest of LLVM.
>>> 
>>> Basically, I would like to introduce a "TGContext" class (by analogy
>>> with LLVMContext) to harbor a proper unique'd type system and BumpPtr
>>> allocate all of TableGen's data (RecTy's, Record's, Init's, etc). This
>>> change should have no effect on the TableGen backends, simply being a
>>> refactoring of the internals.
>> 
>> Makes sense to me.
>> 
>>> One huge bonus in particular from centralizing all of the memory
>>> allocation is that I plan to hack in a custom memory allocator (in a
>>> local branch) which distributes objects randomly in memory, which will
>>> definitively flush out *all* pointer-value-as-map-key non-determinism
>>> inside TableGen.
>> 
>> Cool.  It would also help move the "tblgen as a library" idea closer to reality.
>> 
>>> Does anybody have anything else they think should go into TGContext or
>>> any other responsibilities it should have? Or any feedback about the
>>> idea in general?
>> 
>> All memory allocations should go into its bump pointer, RecordKeeper should as well.  Any other global state that exist should also.
>> 
>>> I'm also hoping that this change should loosen up some of the
>>> calcification that has accumulated on TableGen and get the ball
>>> rolling for transitioning dynamic_cast<> to dyn_cast<> and eliminating
>>> exceptions, along with general improvements in reliability and
>>> performance. Along the way I'm also hoping to pull together proper
>>> reference documentation for the language as it stands right now.
>> 
>> This would be really really great.  Just moving off dynamic_cast is a quite mechanical change that should be straight-forward to do.
>> 
>> -Chris