Hi!
As you may have noticed I'm at changing estimate_num_insns and getting compile time regressions this way. Of course. How do/did we choose the current default inlining limits in the params.def file? While code size estimates from 3.4 to 4.0 changed quite drastically, only one of the inlining limits defaults were changed from 3.4 to 4.0, namely max-inline-insns-auto (from 100 to 120).
I added up the function size estimates for (common) functions compiling mainline with 3.4, 4.0 and 4.0 with the patch at http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01571.html
The results are quite confusing considering we didn't change the inlining limits:
insns
3.4 989098 +0%
4.0 1144765 +16%
4.0 patched 883858 -11%
which either suggests we do not care about such small variations or we are happily enjoying the compile time benefit of inlining less functions on mainline.
There are a few confusing points with the current limits anyway: 1. max-inline-insns-auto is very much lower (120) than max-inline-insns-single (500), while max-inline-insns-recursive is the same as max-inline-insns-recursive-auto (500) 2. 500 is very high for max-inline-insns-single considering that out of all functions in gcc 85% are smaller than this (with the 3.4 estimate). So, effectively we are not limiting inlining of functions marked with "inline" with this limit, but rather with the unit/function growth. Instead our real limit is max-inline-insns-auto with -finline-functions, which is high, too (36% of all functions in gcc are smaller than 100 with the 3.4 counting, 39% smaller than 120 with the 4.0 counting, this includes functions like cp/pt.c:get_class_bindings). 3. we have a large-function growth limit that kicks in only for large functions, but our unit-growth limit kicks in at any starting size.
How did we get to the above limits anyway?
Does anyone have testcases where we can easily see that we have/have not inlined the right stuff? If I take f.i. the MICO package and compile it with 4.0 I get a compile time increase of 3.5% with the patch applied, but I have no ways to test if this has a positive effect elsewhere.
Richard.