This is the mail archive of the
mailing list for the GCC project.
Re: Inlining and estimate_num_insns
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?