[LLVMdev] TableGen: Requesting feedback for "TGContext"

Chris Lattner sabre at nondot.org
Wed Oct 3 20:51:09 PDT 2012

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.


More information about the llvm-dev mailing list