This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Understanding __attribute__((always_inline)) and optimization options
- From: Ian Lance Taylor <iant at google dot com>
- To: Daniel Lohmann <daniel dot lohmann at informatik dot uni-erlangen dot de>
- Cc: gcc-help at gcc dot gnu dot org
- Date: 05 Jan 2007 14:52:56 -0800
- Subject: Re: Understanding __attribute__((always_inline)) and optimization options
- References: <459EB163.3040407@informatik.uni-erlangen.de>
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