This is the mail archive of the 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

Mark Mitchell wrote:
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...


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