This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][C] Fix GNU extern inline heuristic again (fix C++ memory usage regression)
On Wed, Aug 29, 2007 at 10:27:30AM +0200, Paolo Bonzini wrote:
> Ian Lance Taylor wrote:
> >Paolo Bonzini <bonzini@gnu.org> writes:
> >
> >>>Richard, the patch is OK.
> >>I think we should add a note to the manual that GNU "extern inline"
> >>functions are always inlined.
> >
> >By my reading, the documentation already says that. Where you
> >thinking of a specific place to change?
>
> Looking at 4.2 documentation, it never mentioned different inlining
> policies for "GNU extern inline" vs. other inline functions.
>
> I was thinking that, where it says "The definition in the header file
> will cause most calls to the function to be inlined.", we could add
> "because `extern inline' functions are always inlined independent of the
> usual heuristics to limit code growth and of optimization being enabled."
Always inlined is really not true, see below.
> At the end of the paragraph, where "always_inline" is documented, it
> says "GCC does not inline any functions when not optimizing unless you
> specify the `always_inline' attribute". We should say, "When not
> optimizing, GCC only inlines functions that use the GNU `extern inline'
> extension, or that specify the `always_inline' attribute".
This is not true. Try:
extern inline int foo (void) { return 1; }
inline __attribute__((always_inline)) int bar (void) { return 2; }
int baz (void)
{
return foo () + bar ();
}
with any of gcc 3.4.x, 4.1.x, 4.2.x, trunk with -O0 and -O2.
You'll see that at -O2 both functions are inlined, with -O0
extern inline is not inlined (which is correct, GNU extern inline is
not the same as always_inline, not even different just in the required
diagnostic when always_inline can't be inlined). GNU extern inline
functions are not supposed to be inlined with -O0 (-fno-inline to be
precise), they are meant as inline optimized short functions.
Disregarding inline limit is not about overriding -finline/-fno-inline
decision, it is just about assuming the function is small enough,
eventhough the compiler with suboptimal size analysis can't figure that
out.
Jakub