This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]