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.
I see your point now. Some of the hot spots of gcc (cse_insn)
definitly contain bloated conditionals, so this may be effective.
Next time I will read mails more curefully.
Honza
>
> Stn