This is the mail archive of the gcc@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]

Re: Inlining and estimate_num_insns


Jan Hubicka wrote:
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.


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