[LLVMdev] TableGen: Requesting feedback for "TGContext"

[Reed Kotler]

Why do you want to eliminate dynamic_cast and exceptions from tablegen?

This is just a tool run over a few thousand lines of td files.
You can't measure the difference in performance if you eliminate 
dynamic_cast and exceptions.

I think it was a huge mistake to not use RTTI and exceptions in the 
compiler itself but I'm sure that old horse has been beaten to death 
long ago.

But for these small tools, why not use real C++ ?

We seem to make a lot of decisions for the sake of efficiency for things 
that cannot even be possibly measured. Exceptions vs no exceptions in 
the compiler was one of those.

Algorithm complexity and choice is what usually dominates efficiency 
unless you are talking about some tight loop in the kernel of an OS.
Micromanaging small things usually ends up making things more 
complicated and in the end; slower, bigger, more error prone and harder 
to maintain.

My 2c.

Reed

On 10/03/2012 07:07 PM, Sean Silva 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.
>
> 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.
>
> 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?
>
> 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.
>
> -- Sean Silva
>