[LLVMdev] TableGen: Requesting feedback for "TGContext"

[Sean Silva]

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