llvm dev - Oct 2012 - [LLVMdev] TableGen: Requesting feedback for "TGContext"

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

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

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

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.
> 
> 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.
Huge +1. This is awesome.

Along the same lines as removing RTTI and exceptions is that TableGen could
really use a StringRef'ization and more use of the ADT containers in
general. That's pretty orthogonal to what you're proposing here, though,
so certainly not required. Just something to keep in mind as you work through
the code if you're in the mood for some incremental cleanup along the way.


-Jim
> 
> -- Sean Silva
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

> Along the same lines as removing RTTI and exceptions is that TableGen could
really use a StringRef'ization and more use of the ADT containers in
general. That's pretty orthogonal to what you're proposing here, though,
so certainly not required. Just something to keep in mind as you work through
the code if you're in the mood for some incremental cleanup along the way.
Pretty much all of this stuff is "incremental cleanup" ;) I'll
definitely put those things in the queue. Thanks for the feedback!

-- Sean Silva

On Thu, Oct 4, 2012 at 2:03 PM, Jim Grosbach <grosbach at apple.com>
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.
>>
>> 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.
>
> Huge +1. This is awesome.
>
> Along the same lines as removing RTTI and exceptions is that TableGen could
really use a StringRef'ization and more use of the ADT containers in
general. That's pretty orthogonal to what you're proposing here, though,
so certainly not required. Just something to keep in mind as you work through
the code if you're in the mood for some incremental cleanup along the way.
>
>
> -Jim
>>
>> -- Sean Silva
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

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
>

> 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.
This isn't about performance. It's about bringing it up to snuff with
the rest of the codebase. And btw it's not "a few thousand lines",
it's >125K lines. It's also not "a small tool"; it's a
critical piece
of infrastructure for the project and the current state of affairs
poses a bottleneck for certain kinds of improvements in relevant areas
(like, say, *all* the targets).
> 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.
Well, this is certainly not being done for the sake of efficiency.
While we don't want to make TableGen excessively slow, since that
impacts oh-so-precious build time, TableGen is not really the target
of any optimization effort (certainly not by me, nor by anybody else
AFAICT).

Most of the changes that I am proposing are primarily to make it more
self-contained and maintainable. Also, once TableGen is up to snuff
with the rest of the codebase and its current de facto behavior is
documented, it will be possible to coherently take directions on
improving the language, which could have significant positive benefits
across the codebase by e.g. making target descriptions easier to write
and maintain.
> 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.
Indeed. Generating the .inc files actually is a small fraction of the
build time. However, the number of files dependent on those .inc files
is huge, and the current state of affairs is that if anything that any
single piece of TableGen depends on is touched, then *everything* that
depends on TableGen in any way needs to be rebuilt. So for example,
changes to utils/TableGen/X86ModRMFilters.cpp will cause the Mips
backend (and indeed, a large part of the world) to be rebuilt. A more
modular TableGen would allow for these dependencies to be properly
specified, for example. That is an example of an algorithmic
improvement that we can expect to see come out of this work.

The first step though is whipping all of the code into shape, because
currently trying to do higher level improvements like those I just
described is like playing chess surrounded by a swarm gnats so thick
that you don't want to breath for fear of getting one in your lung.

-- Sean Silva

On Thu, Oct 4, 2012 at 9:29 PM, Reed Kotler <rkotler at mips.com>
wrote:
> 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
>>
>

On Thu, Oct 04, 2012 at 06:29:15PM -0700, Reed Kotler
wrote:
> Why do you want to eliminate dynamic_cast and exceptions from tablegen?
Because for many, it is the only reason why some libraries have to be
compiled with RTTI and exception support.

Joerg