This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc compile-time performance
Jan Hubicka wrote:
>
> > Another idea is to use gcov to identify areas of code that are
> > always dead for a particular config, then look at the
> > conditionals that guard the dead area. There are probably
> > cases where the conditionals are not ordered for maximal
> > efficiency. (Of course it's possible that a good ordering
> > for one config is bad for another.) The gcov route could also
> > identify more opportunities to GC code for obsolete configs.
>
> Unfortunately GCOV also brings relatively balanced results.
> The hottest place according to the GCOV are comment skipping loops
> in the preprocessor that already has been microoptimized.
Right, but I'm talking about doing the opposite - looking at code
that gcov says is dead, and then either deleting it because it
really is dead, or shrinking the time that the guarding conditionals
spend deciding to go around the not-quite-dead code. GCC (and GDB)
are notorious for their multi-page if-conditions, and profiling
can't tell you whether the conditional is executing 500 extra
instructions because the tests are in a poor order.
Stn