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
I'll