Re: inlining not done (-Winline -o3)

[Guy Harrison]

Attila Feher wrote:

> Hi,
> 
> I am trying to figure out how g++ decides when to inline.

It varies on g++ version. You'd have to look at its sources to tell for
sure.

> I have big 
> templated code, consisting mostly of small functions.  I expected most of
> the to be inline - as they were declared/defined inline, and I do optimize
> with -O3.  Out of curiosity I have tried the -Winline argument to check
> what
> does not get inlined.  To my utter surprise, even fairly simple forwarders
> are reported not to be inlined.  The online gcc documentation promises
> that -Winline will tell the reason why inlining was not done.  But it
> doesn't.  The docu also lists the possible reasons for not inlining, none
> of
> which applies to my functions.  So I am lost. :-(
> 
> Where can I find a description of inlining in g++?

Dunno I'm afraid.

> Or is there a way I 
> can force g++ to tell me why the inlining was not done?

Not that I'm aware of.
 
> I am using 3.4.2, MingW.

MingW or not shouldn't make much difference here. I rarely have to code on
the bleeding edge so inline/not-inline doesn't make a lot of difference
here. Subjectively, I have noticed 'inline' is largely "ignored" in that
code won't be inlined when optimisation is too low (even when 'inline'
keyword is present) and will be inlined anyway (even without 'inline'
keyword) once optimisation level is set high enough. For 3.x "-O3" will
inline where it can.

Bearing in mind "I dunno" in conjunction with "that's so trivial it should
have been inlined" perhaps you have a situation where g++ has already
instantiated an "outline" specialisation which may have the effect of
cancelling out future inline candidates? A hypothesis, EG: if at some point
the template body was not available at the time of reference I can envisage
the compiler being forced to fall back on a distinct subroutine call.