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:44:00 -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:
> > So... Don't you think that if we spent more
> >time getting the infrastructure faster, -O0 will improve as well?
> Well sure, it should be part of the plan.
> One of my suspicions is that the massive use of macros in tree
> and RTL is concealing excessive pointer chasing, because they
> don't show up in either profile or coverage numbers
Ding ding, you have another winner.
I actually benched this once, by functionizing some often used macros.
The timings were horrendous.
But what can we do to increase cache locality, or get rid of these
> is taking the macros that we function-ized for debugging purposes
> (Ira posted it to gcc-patches some time ago, but nobody wanted it
> because dwarf2 macro debugging was going to be available RSN), and
> will build a (slow) GCC that will do it all through function calls.
> That should yield a much more interesting profile.
> I don't think Mike mentioned it, but speeding up the compiler has
> become our group's top priority, and every idea is on the table
> right now. The 6x goal sounds extreme, but it helps keep in mind
> that one or two or even a dozen 5% improvements will not be
> sufficient to attain parity with the competition.
I think part of the problem is that the timings gcc itself outputs aren't
completely accurate, because sometimes we go around the calls that would
push the timevar.