Re: 3.0 c++ and -finline-limit oddities

[Teemu Torma <tot at trema dot com>]

Joe Buck wrote:
> 
> >
> > I have been testing 3.0 branch for some time, and noticed the following
> > oddity when trying to use -finline-limit to avoid huge code bloat.
> >
> > In the following example, when starting with small limit value and start
> > increasing it, I would have _expected_ that the first thing is that
> > calls to `d' would be first ones to get inlined, and after that calls to
> > `c', `b' and finally `a'.   However, in a x86 linux box with -O
> > -finline-limit=80, the calls to `a' and `c' are inlined, whilst calls to
> > `b' and `d' are not.  I bit odd, since the biggest benefit would come
> > from inlining `d'--it might even return a constant value and thus
> > benefit the rest of the optimization.
> 
> I think that you need to reorder the code.  gcc has difficulty inlining
> functions in cases where the caller precedes the called function; one
> level of calling works but it seems two or more do not.
> 
> Try putting d before c before b before a and repeating the test.

I does not change anything.  Current version seems to be pretty good at
inlining regardless the order of declarations, unlike some older
versions.

Besides, things like STL are full of inlinable code like my example.

Teemu