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

[Daniel Lohmann <daniel dot lohmann at informatik dot uni-erlangen dot de>]

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