Re: Inlining and estimate_num_insns

[chris jefferson <caj at cs dot york dot ac dot uk>]

> 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