3. Richard's attempt to discount stuff from being counted unnecessarily in return statements makes sense to me.
I shifted from avoiding duplicated counting here and there to the goal
that the inliner should not pessimize abstraction by indirection, that
is, the accounted size for accessing a class member should be the same
as the accounted size for an inlined access member function. That this
property results from the neglecting of stores to variables that are
marked with DECL_IGNORED was pure luck, I think. And ignoring all stores to DECL_IGNORED variables is possibly not the best solution to
this problem, but surely the simplest and as such the only that would
be appropriate for 4.0 if any at all.
I think it would be worthwhile to have a set of testcases that verify the properties we want to have of an inliner / code size estimator. But of course I'm at the moment trying to solve my (and some others) speed regressions for 4.0.
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?
While in theory this could work well, existing code-bases (such as POOMA) are notoriously bad in consistently using "inline" (or not). I
guess such scheme would work great for most C people, as C people
generally think twice before using inline or not (at least this is
my experience). I'd rather have the C++ frontend ignore "inline" completely and enable -finline-functions by default and tell people
to use profile-directed inlining that we probably get for 4.1.
So, for 4.0, I don't really know what to do - the patch doesn't really affect C code, only certain classes of C++ code where we now inline a lot more (large) functions because the limits are not throtled artificially by abstraction any more. Then with people using too much "inline" or in-class definition of methods, we simply inline until hitting the function or unit growth limits (which are high), because our size limit for inlining inline marked functions is so high.
All classes of patches in this fragile area, for 4.1, too, are subject to nasty surprises. The question is wether we want to do an experiment on the HEAD branch with the patch and some reduced default inlining limits or not. I guess I personally do not care so much for 4.0 (as I did for 3.3 and 3.4), because I only use gcc with custom patches like leafify, but more often that I want I end up pointing people at the lab at the better-compiler-in-my-home-directory...
Richard.