Re: -fno-inline-functions vs glibc's initfini

[Richard Guenther <richard dot guenther at gmail dot com>]

On Tue, Jan 31, 2012 at 2:31 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> glibc 2.15 won't build with GCC 4.7ish on ppc64: -fno-inline-functions
> is no longer enough to prevent call_gmon_start from being inlined into
> initfini.c's _init, as required by glibc's somewhat convoluted
> compilation of initfini.c into crt*.o. ?As a result of the inlining, a
> branch and its target label end up in separate object files, after the
> compiler's assembly output is broken up in pieces.

-fno-inline-functions is the default at -O[012s] - you probably want
-fno-inline.

> I suppose this could be easily worked around in glibc, by using
> attribute noinline (and noclone, for good measure, for partial inlining
> of the gmon_start undef-weak test would be just as damaging), or
> compiling sysdeps/generic/initfini.c with
> -fno-inline-functions-called-once (if available), and perhaps also
> -fno-inline-small-functions, -fno-indirect-inlining and
> -fno-partial-inlining, with room for whatever other options we GCC
> developers come up with to control other cases or kinds of inlining.
>
> I'm a bit surprised that -fno-inline-functions doesn't imply all of
> these, as long as they're not specified explicitly. ?IMHO it should.

No, it should not.  -finline-functions simply considers all functions
not declared inline as if they were declared inline.  -fno-inline-functions
simply does _not_ do that - it does not affect whether not inline
declared functions are inlined.

> I'm also surprised that some parts of GCC appear to assume that
> -fno-inline was supposed to behave that way, preventing any inlining
> whatsoever.

That's what it is supposed to do.

> Grepping for flag_no_inline shows some hits that appear to
> indicate some confusion as to its meaning.

I think you are confused here ;)

> To make matters worse for glibc, it appears that at least
> -finline-functions-called-once is already present in earlier releases of
> GCC, which means we might have no choice but to bite the bullet and use
> this option if it's available, even though I have no evidence that the
> implementation controlled by the option caused any problems to glibc's
> initfini compilation in already-released versions of GCC.
>
>
> So, where do we go from here? ?Is there any reason why glibc doesn't use
> the noinline attribute in sysdeps/generic/initfini.c, or for glibc not
> to auto-detect -fno-inline-functions-called-once et al and use them in
> addition to -fno-inline-functions to compile initfini.c?

It should simply use -fno-inline if it wants to disable inlining (and we should
consider dropping -f[no-]inline-functions).

> As for GCC, shouldn't we aim at providing a stable, reliable option that
> prevents inlining of functions not marked always_inline, regardless of
> special cases and exceptions to the general inlining rules we might come
> up with in the future?

That's -fno-inline.

@item -fno-inline
@opindex fno-inline
Don't pay attention to the @code{inline} keyword.  Normally this option
is used to keep the compiler from expanding any functions inline.
Note that if you are not optimizing, no functions can be expanded inline.

What's probably confusing you is the "Don't pay attention to the
@code{inline} keyword" sentence.  If you drop that it's clear what the
switch does.

I suppose we should clarify the documentation and I will prepare a patch.

> ?Also, shouldn't the implementation of
> -finline/-fno-inline be adjusted to match the documentation, and have
> flag_no_inline_functions become what we test for as flag_no_inline in
> some functions that make decisions about whether or not to perform
> inlining?

The implementation is exactly right, it might be the documentation
is a bit confusing.

Richard.

> Thanks in advance for feedback and suggestions,
>
> --
> Alexandre Oliva, freedom fighter ? ?http://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/ ? FSF Latin America board member
> Free Software Evangelist ? ? ?Red Hat Brazil Compiler Engineer