100x -O0 Compile Time Regression {3.2,3.3} -> {3.4,3.5}

[law@redhat.com]

In message <402C22D9.6020306@xza5.com>, John Vickers writes:
 >Zack Weinberg wrote:
 >> The most efficient way to track this down is probably to apply a
 >> function-level profiler (oprofile is convenient as it doesn't require
 >> recompiling anything; gprof also works; I can supply instructions for
 >> building the compiler with gprof instrumentation if you like)
 >
 >Hmm.  oprofile.  Cool.
 >
 >But recompiling gcc with gprof might be easier.  If you have a
 >canned recipe, that would be handy.
The problem with gprof is that it can significantly skew the results.

oprofile is non-intrusive and you can use it on existing binaries without
needing to recompile them.

Jeff

ps.  Trivia question for the rest of the list.  What routine gets the most
amount of cpu time doing a "make -k check" from the toplevel of the
source tree after a 3-stage bootstrap (tree-ssa branch).....


et_splay with a whopping 27% of all the events within cc1 (cc1 has just over
40% of the total events during make-k check run).

Clearly there's one or more tests which are pounding the dominator/et-forest
code in ways we never expected since I rarely, if ever see et-splay on the
profiles....


Jeff