Re: Inlining and estimate_num_insns

[Mark Mitchell <mark at codesourcery dot com>]

A few top-level comments on this thread:

1. The C++ community has split into two sub-communities.  One is very 
heavily focused on template metaprogramming.  The other is doing more 
"traditional" object-oriented programming.  The kinds of programs 
written by these two communities are drastically different, even though, 
obviously, there is overlap between the two, mixed programs, etc.  But, 
programmers in one camp tend to think that their style is "very common" 
while that of the other camp is "fancy" or "complicated".  The truth is 
that both are now mainstream uses of C++, and we need to try to work 
well with both kinds of code.

2. I don't think we should be make any changes at this point without a 
relatively comprehensive benchmarking effort.  That means more than a 
few programs, compiled on multiple architectures, with measurements of 
both compile-time and runtime performance.  I'd suggest that tramp3d is 
fine, but I'd also suggesting looking at KDE, Boost, and libstdc++-v3. 
I'd try to measure total compilation time, total code size, and some 
measure of performance.  (Since C++ inlining should generally -- but not 
always, of course -- result in smaller code due to removal of calls, 
code size is probably a rough proxy of performance.)

3. Richard's attempt to discount stuff from being counted unnecessarily 
in return statements makes sense to me.

4. I don't see any reason to think that an inliner tuned well for C++ 
would not also work well in C, though the opposite might not be true. 
(People using inline heavily in C are generally writing code that looks 
relatively similar to OO C++ programs.)

5. However, it really might be sensible to have the C++ front end treat 
"inline" as a command, rather than a hint, by default.  It might be that 
explicit uses of inline should be pretty much unconditionally honored. 
(I'd say that functions defined in a class, but not marked inline, 
should not be given this behavior.  That's partly because other 
compilers already treat "inline" in a class definition as more emphatic 
than just defining the function there, so there's a body of existing 
code out there that relies on this.)  I suspect that having the C++ 
front end treat "inline" as a command would fix most of the C++ inlining 
problems without requiring any tuning of the inlining algorithms.  Has 
anybody experimented with that potentially much less intrusive fix?

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304