3.0 c++ and -finline-limit oddities

[Teemu Torma <tot at trema 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 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