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



I take it as a lame property of our current inlining heuristics and function size estimate that for

  inline int foo { return 0; }
  int bar { return foo(); }

the size estimate of foo is 2, that of bar is initially 13 and 5
after inlining.  3.4 did better in that it has 1 for foo, 12 for bar
before and 3 after inlining.  Though one could equally argue that
3.4 had an abstraction penalty of 3.0 while 4.0 now has 2.5.

It is not hard to believe that for C code this does not matter much,
but for C++ it effectively lowers our inlining limits as at least
things like accessor methods are very common, and if you think of
template metaprograms, with the old scheme we're just loosing.

While so far the inliner has been coping, it is worth pointing out that more abstractions working their way into libstdc++, for example the next version of libstdc++ now has a shared implementation of sorting with and without a predicate, by using the predicate "bool less(const T& a, const T&b) { a < b;}" (not actual implementation!) when no predicate is specified.

In the near future more such code may (hopefully) be introduced to allow the same implementation of sort deal with more specialiastions without having to duplicate large sections of code. Assuming the inliner does its work, then in most cases once inling has been performed the resulting code can be smaller than the function call it is replacing. I would personally say that it is very important that the inliner is capable of realising when a number of very small nested functions will collapse to almost no code at all.

Chris


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