Understanding __attribute__((always_inline)) and optimization options

Understanding __attribute__((always_inline)) and optimization options

[Daniel Lohmann]

Env: gcc/g++ 3.4.x

Hi folks,

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 :-)]


** 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.]


** 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.]


** 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.


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


Any clarification is highly appreciated.

Thank you very much!

Daniel Lohmann

Re: Understanding __attribute__((always_inline)) and optimization options

[Ian Lance Taylor]

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

Re: Understanding __attribute__((always_inline)) and optimization options

[Daniel Lohmann]

Ian Lance Taylor schrieb:
> Daniel Lohmann <daniel.lohmann@informatik.uni-erlangen.de> writes:
> 
>> ** 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.  

Thanks for the clarification.

> The inline keyword is not in general
> obsolete.

Well, of course.


>> ** 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

Hideous, you name it... In fact I did read this section - several times. I 
have to admit that I still do not understand it completely. (IMHO this is 
by far the most difficult to read section of the GCC manual, it would 
significantly benefit from more (simple) examples.)

Now, after reading it once again, I have the feeling that a, b, c produce 
the same result - at least in all non-obscure cases.

>> ** 3) This is particularly important with the following: Is it
>> necessary to have an explicit prototype declaration 
 >> [...]
> 
> It is not necessary to have an explicit prototype.

That are good news, thanks!

>> ** 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:
>> [...]
> 
> The option is -funit-at-a-time.

Oh, I never considered that one to influence inlining. Make sense, though.

Ian, thank you very much!

Daniel