To just add another data-point, metaprograms like the following are very common. Consider
template <int i> struct Add { static inline int doit(int *x) { return Add<i-1>::doit(x)+x[i]; } }; template <> struct Add<0> { static inline int doit(int *x) { return x[0]; } }; template <int i> inline int add(int *x) { return Add<i>::doit(x); }
int foo(int *x) { return add<3>(x); } int bar(int *x) { int i, r=0; for (i=0; i<4; ++i) r += x[i]; return r; } int baz(int *x) { return x[0]+x[1]+x[2]+x[3]; }
The size estimates after inlining (before in paranthesis) are foo bar baz 3.4 12 (11) 11 7 4.0 29 (13) 18 17 4.0 patched 6 (10) 11 6
which shows: 1. estimates for 4.0 are way higher than for 3.4 in general (while we still have the same inlining limits) 2. INSNS_PER_CALL (10) is low for 4.0 compared to 3.4 if you consider the overall increase. Something like at least 15 would be appropriate. 3. the new size estimate for 4.0 produces slightly lower estimates than 3.4 which suggests to at least change max-inline-insns-auto back to 100 as it was in 3.4 from now 120.
Also we might experiment with modifying your patch so it ignores assignments to aritifical temporaries, only when they match gimple register criteria - that way we won't think that structure to structure assignments and firends are cheap and get back to 3.4 sizes. Without early optimization there is no real reason for the size estimates to be smaller than in 3.4.
Maybe - one thing I noticed (missed) during debugging of all this stuff
is a way to print a <statement-list> in gdb - is there some convenient
way like debug_tree or debug_c_tree that prints these? I'd like to know
what exactly representation we are feeding to estimate_num_insns, it
should be similar to the generic dump, but knowing it for sure would be great.
Thanks, Richard.
