This is the mail archive of the gcc-help@gcc.gnu.org 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: Understanding __attribute__((always_inline)) and optimization options


Daniel Lohmann <daniel.lohmann@informatik.uni-erlangen.de> writes:

> According to the GCC User Manual one can force a function to be
> inlined using the always_inline attribute:
> 
>  >>>>>>>>
> 5.34 "An Inline Function is As Fast As a Macro")
> 
> ...
> GCC does not inline any functions when not optimizing unless you
> specify the 'always_inline' attribute for the function, like this:
> 
> /* Prototype. */
> inline void foo (const char) __attribute__((always_inline));
> <<<<<<<<
> 
> Now, I have a couple of questions:
> 
> ** 1) As I understood the description of always_inline, the inline
> keyword in the above example is obsolete, right?
> [According to my tests this seems to be the case, but want to be sure :-)]

If you use the always_inline attribute, then, yes, you do not need to
also use the inline keyword.  The inline keyword is not in general
obsolete.

> ** 2) Is it necessary for the attribute declaration to be at the *end*
> of the prototype declaration? In other words, is there any difference
> between:
> 
> a: void foo(const char) __attribute__((always_inline));
> b: void __attribute__((always_inline)) foo(const char);
> c: __attribute__((always_inline)) void foo(const char);
> 
> [According to my tests all three of them seem to produce the intended
> result, meaning that foo() is always inlined.]

You can find all the hideous details here:
    http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Attribute-Syntax.html

> ** 3) This is particularly important with the following: Is it
> necessary to have an explicit prototype declaration of such function
> or can always_inline also be applied to functions that are implicitly
> declared by their definition:
> 
> // Implicit prototype by definition. However, always inlined?
> __attribute__((always_inline)) void foo(const char c) {
>     ... some code
> }
> 
> struct A {
>    // An in-place defined member function that is always inlined?
>    __attribute__((always_inline)) foo() {
>      ... some code
>    }
> };
> 
> [Again, this seems to work - but I have to make it sure.]

It is not necessary to have an explicit prototype.

> ** 4) Which option enables "backward inlining" in gcc? When using
> always_inline the compiler issues a warning if the function can not be
> embedded into the caller for some reason:
> 
> inline void foo (const char) __attribute__((always_inline));
> 
> int main() {
>    foo('x');
> }
> 
> inline foo(const char c) {
>    // foo definition
> }
> 
> The warning is issued in this case as the definition of foo() is not
> available when main() is compiled. However, with -O2 or better
> optimizations, gcc performs a kind of "backward inlining", meaning
> that even function definitions that are further ahead in the source
> file can be embedded into a caller. Consequently, the warning
> disappears as soon as one uses at least -O2 optimizations. Is there
> any specific option responsible for this behavior? I would like to
> enable "backward inlining" even with -O1 or -O0.

The option is -funit-at-a-time.

> **5) Could there be any situation, where a function with always_inline
> is _silently_ not embedded?

I hope not.  I don't know of any.

Ian


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