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

[Joe Buck <jbuck at synopsys dot COM>]

> 
> 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 noticed this behaviour whilst testing template code generation and
> ways to reduce the inlining in a real code.  The worst thing I notices
> was lack of inlining the smallest bits (`d' in this example) returning
> const values, and thus resulting much worse code than with everything
> inlined.
> 
> Configured with: ../gcc-3.0-branch/configure
> --with-gcc-version-trigger=/work/tot/gcc/3.0/gcc-3.0-branch/gcc/version.c
> --host=i686-pc-linux-gnu --prefix=/usr/local/gcc3
> --enable-version-specific-runtime-libs --enable-long-long
> Thread model: single
> gcc version 3.0 20010506 (prerelease)
> 
> struct X
> {
>   double v;
> 
>   inline double a () { return b () * (b () / (b () * 19)); }
>   inline double b () { return c () / (c () * 0.99912 + c () * 0.88822);
> }
>   inline double c () { return d () * d () - d () / 2; }
>   inline double d () { return v; }
> };
> 
> double
> test (X &x)
> {
>   return x.a ();
> }
> 
> Teemu
>