This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inlining and estimate_num_insns
Richard Guenther wrote:
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.
Of course, if we can make the compiler automatically do the right thing,
that's great. What I'm proposing is a method that would be possibly
acceptable for 4.0 that would give people an easy to understand way of
getting the compiler to do what they want: put "inline" on functions
they really want to have inlined. That's in addition to the existing
heuristics. I think that's a plausible way of mitigating the problem
for people in the short term.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304