This is the mail archive of the
mailing list for the GCC project.
Re: Faster compilation speed
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Stan Shebs <shebs at apple dot com>
- Cc: Aldy Hernandez <aldyh at redhat dot com>, Mike Stump <mrs at apple dot com>,<gcc at gcc dot gnu dot org>
- Date: Fri, 9 Aug 2002 20:36:31 -0400 (EDT)
- Subject: Re: Faster compilation speed
- Reply-to: dberlin at dberlin dot org
On Fri, 9 Aug 2002, Stan Shebs wrote:
> Aldy Hernandez wrote:
> >>Let's take my combine elision patch. This patch makes the compiler
> >>generate worse code. The way in which it is worse, is that more stack
> >>space is used. How much more, well, my initial guess is that it is
> >>less than 10% worse. Not too bad. Maybe users would care, maybe they
> >I assume you have already looked at the horrendity of the code
> >presently generated by -O0. It's pretty unusable as it is. Who would
> >really want to use gcc under the influence of "worse than -O0"?
> OK, then to really rub it in, CW runs much faster than GCC, even on
> that slow Darwin OS :-), and that's with its non-optimizing case being
> about halfway between GCC's -O0 and -O1, and works well with the
> debugger still.
> Sacrificing -O0 optimization is just a desperation move, since
> we don't seem to have many other ideas about how to make GCC as
> fast as CW.
Look, there are, in reality, two things that make our compiler slower
than metrowerks, even at -O0
First is parsing.
The bison parser is just not fast. It never will be.
The second is expansion from tree to RTL.
It's not fast either. The timings don't always tell the real story. There
are cases where expansion is occuring when the timevar isn't pushed (IE
other things that call expand_*, where * = anything but _body, where the
timevar is pushed).
The solutions to the first is already in progress (give me a clean,
working hand-written parser, that can compile libstdc++, and i'll happily make it
go real fast. I was just starting to when the branch was abandoned.).
Codewarrior, for comparison sake, uses a backtracking recursive descent
parser for it's C++ compiler.
The second is hard to solve in a way people would like. The fastest way
to solve the problem is to do native code generation off the tree at -O0,
avoiding any optimizations whatsoever.
This is, of course, not easy to do with our current MD files.
We really would need a *burg like tool and associated descriptions.
You could do debugging output without too much difficulty. Most of the
debug_* functions operate on trees anyway.
PFE solves our first problem as well, but not the second one. We still
have to *generate* the code.
But there still have to be better answers than trying to avoid the backend
entirely. If our backend is so godawfully bad that we have to start
skipping entire "normal" phases (IE not optimizations to speed up code,
or things that are done in plenty of other compilers at -O0), then we
really *do* need to rearchitect them, and maybe more.
Not just directed speed ups.
At some point, it becomes easier to redo it from scratch well.
Particularly when nobody today understands why anyone thought it was a
good idea to do it the way it's done now.