[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.
-Chris
More information about the llvm-dev
mailing list