[LLVMdev] TableGen: Requesting feedback for "TGContext"

[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
>>
>