[Bug web/61782] New: always_inline incorrectly documented

[Bug web/61782] New: always_inline incorrectly documented

[daniel.santos at pobox dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782

            Bug ID: 61782
           Summary: always_inline incorrectly documented
           Product: gcc
           Version: 4.8.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: web
          Assignee: unassigned at gcc dot gnu.org
          Reporter: daniel.santos at pobox dot com

The current behavior of __attribute__((always_inline)) is to not only inline in
-O0, but also to force inlining even when -finline-limit is exceeded. However,
the documentation states that it will only cause inlining w/o optimizations:

https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007balways_005finline_007d-function-attribute-2864

We had some discussion about this in LKML some time back and I meant to file a
bug report back then, but just remembered. This should be updated to reflect
the current behavior of always_inline.

[Bug web/61782] always_inline incorrectly documented

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-07-14
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
?

@item always_inline
@cindex @code{always_inline} function attribute
Generally, functions are not inlined unless optimization is specified.
For functions declared inline, this attribute inlines the function even
if no optimization level is specified.

what exactly is unclear about this?  "even if no optimization level is
specified"

The implemented behavior is that always_inline forces inlining of the function
under all circumstances and it is an error if the function cannot be inlined.

[Bug web/61782] always_inline incorrectly documented

[daniel.santos at pobox dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782

--- Comment #2 from Daniel Santos <daniel.santos at pobox dot com> ---
Hmm, I suppose I wasn't considering that interpretation of the language. Your
clarification helps though, and actually sounds pretty good: "always_inline
forces inlining of the function under all circumstances and it is an error if
the function cannot be inlined."

I know that I am not the only person who has read the original language and
interpreted it as marking the function inline-able, even if if inlining
(-finline-functions) isn't enabled, yet still subject to other considerations
for a determination as to rather or not the function body is actually inlined,
(i.e., the inline insn count).

So can we get some clarification similar to the language you used above?

[Bug web/61782] always_inline incorrectly documented

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Like

@item always_inline
@cindex @code{always_inline} function attribute
Generally, functions are not inlined unless optimization is specified.
For functions declared inline, this attribute inlines the function 
independent of any restrictions that otherwise apply to inlining.
Failure to inline such function is diagnosed as error.
Note that if such function is called indirectly the compiler may
or may not inline it dependent on optimization level and a failure
to inline an indirect call may or may not be diagnosed.

which matches how GCC behaves (last sentence)?

Corrections welcome (I am not a native speaker).

[Bug web/61782] always_inline incorrectly documented

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> Like
> 
> @item always_inline
> @cindex @code{always_inline} function attribute
> Generally, functions are not inlined unless optimization is specified.
> For functions declared inline, this attribute inlines the function 
> independent of any restrictions that otherwise apply to inlining.
> Failure to inline such function is diagnosed as error.

Failure to inline such a function is diagnosed as an error.
                       ^                          ^^

> Note that if such function is called indirectly the compiler may

Note that if such a function is called indirectly the compiler may
                  ^

> or may not inline it dependent on optimization level and a failure

I think I'd say s/dependent/depending/ here.

> to inline an indirect call may or may not be diagnosed.

[Bug web/61782] always_inline incorrectly documented

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Patch posted.

[Bug web/61782] always_inline incorrectly documented

[daniel.santos at pobox dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782

--- Comment #6 from Daniel Santos <daniel.santos at pobox dot com> ---
(In reply to Richard Biener from comment #3)
> Note that if such function is called indirectly the compiler may
> or may not inline it dependent on optimization level and a failure
> to inline an indirect call may or may not be diagnosed.

OMG!! Thank you SO much for this clarification! I'm the crazy C metaprogramming
guy and I depend upon -findirect-inline and always_inline to facilitate what
I'm calling "C pseudo-templates." This would explain some odd circumstances
where I've seen such functions not get inlined. I've been able to remedy this
(thus far) by marking the calling function with __attribute__((flatten)), but I
have to take great care to catch this, ensuring that that I check each value
that I expect to be constant with __builtin_constant_p and generate an error
when they aren't.

Portions of these functions (often the majority) I expect to be executed by the
compiler and the result emitted, rather than having the whole of the function
emitted as generated code. As the complexity of such functions grows, the cost
of failing to inline by indirection can be the explosion of the function to 10,
20 times or more of it's size when all inlining happens. (sorry, that's a
little off topic).

I like the verbiage and thank you!

[Bug web/61782] always_inline incorrectly documented

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 15 Jul 2014, daniel.santos at pobox dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782
> 
> --- Comment #6 from Daniel Santos <daniel.santos at pobox dot com> ---
> (In reply to Richard Biener from comment #3)
> > Note that if such function is called indirectly the compiler may
> > or may not inline it dependent on optimization level and a failure
> > to inline an indirect call may or may not be diagnosed.
> 
> OMG!! Thank you SO much for this clarification! I'm the crazy C 
> metaprogramming guy and I depend upon -findirect-inline and 
> always_inline to facilitate what I'm calling "C pseudo-templates." This 
> would explain some odd circumstances where I've seen such functions not 
> get inlined. I've been able to remedy this (thus far) by marking the 
> calling function with __attribute__((flatten)), but I have to take great 
> care to catch this, ensuring that that I check each value that I expect 
> to be constant with __builtin_constant_p and generate an error when they 
> aren't.

Heh - I've been there as well and guess what - I invented 
__attribute__((flatten)) because of this...

Note that flatten has the same issues as always_inline with respect
to indirect function calls (or virtual method calls, which are
indirect calls).

> Portions of these functions (often the majority) I expect to be executed by the
> compiler and the result emitted, rather than having the whole of the function
> emitted as generated code. As the complexity of such functions grows, the cost
> of failing to inline by indirection can be the explosion of the function to 10,
> 20 times or more of it's size when all inlining happens. (sorry, that's a
> little off topic).

Yeah, similar catastrophic things happened in the past with 
profile-feedback where instrumentation was applied _before_ all 
inlining... (I changed that as well).

[Bug web/61782] always_inline incorrectly documented

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.10.0

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for 4.10.

[Bug web/61782] always_inline incorrectly documented

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Wed Jul 16 07:53:59 2014
New Revision: 212581

URL: https://gcc.gnu.org/viewcvs?rev=212581&root=gcc&view=rev
Log:
2014-07-16  Richard Biener  <rguenther@suse.de>

    PR other/61782
    * doc/extend.texi (always_inline): Clarify.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/doc/extend.texi

[Bug web/61782] always_inline incorrectly documented

[daniel.santos at pobox dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61782

--- Comment #10 from Daniel Santos <daniel.santos at pobox dot com> ---
(In reply to rguenther@suse.de from comment #7)
> Heh - I've been there as well and guess what - I invented 
> __attribute__((flatten)) because of this...
> 
> Note that flatten has the same issues as always_inline with respect
> to indirect function calls (or virtual method calls, which are
> indirect calls).
> 
> > Portions of these functions (often the majority) I expect to be executed by the
> > compiler and the result emitted, rather than having the whole of the function
> > emitted as generated code. As the complexity of such functions grows, the cost
> > of failing to inline by indirection can be the explosion of the function to 10,
> > 20 times or more of it's size when all inlining happens. (sorry, that's a
> > little off topic).
> 
> Yeah, similar catastrophic things happened in the past with 
> profile-feedback where instrumentation was applied _before_ all 
> inlining... (I changed that as well).

Hah! That makes you my hero then! I haven't learned the internals of gcc yet,
so I still have to rely on others for this fringe stuff.

Thanks again everybody.