> 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.
Honza
>
> Richard.
