This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
- From: "lucier at math dot purdue dot edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 Feb 2009 21:58:11 -0000
- Subject: [Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines
- References: <bug-26854-271@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #93 from lucier at math dot purdue dot edu 2009-02-14 21:58 -------
Subject: Re: [4.3/4.4 Regression] Inordinate compile times on large routines
I instrumented the compiler and looked how many nodes were in each
loop processed by LICM for the Gambit runtime and compiler.
For generated code, except for the "loop" that contained the entire
function, the greatest number of nodes was 30. (Because computed
gotos are used in the code that checks for heap and stack overflows
after allocations and for waiting interrupts, it's hard to go long in
Scheme code without hitting the "big loop".) For hand-written code,
the greatest number of nodes in a loop was 123.
When bootstrapping gcc with --enable-languages=c, the largest number
of nodes in a loop was 803, and there were 12 loops detected that had
over 500 nodes. 548 loops had 100 nodes or greater. (This is a
bootstrap, so some files were compiled twice with the instrumented
compiler.)
So perhaps an -O1 default for LICM of 100 nodes is reasonable, or
perhaps one might up it to 1000 just to catch everything "reasonable".
Brad
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854