Hi Gerald,

On Fri, Apr 26, 2002 at 01:10:18PM +0200, Gerald Pfeifer wrote:
> C++ and C now both use the tree based inliner.

Yes, but are there languages that do use the RTL inliner still?

> > Maybe one should separate those issues and verify that do what my
> > intention was.
> 
> Yes, that might make sense.

I'll put three patches up then ...

> >>                      build time   binary size
> >>   2.95.3                   4:01   4430752
> >>   3.0                     23:54   6295044
> >>   3.0.3                    3:58   3948444
> >>   3.1-20020422             4:38   3996096  <-- without patch
> >>   3.1-20020424+kurt-v3     5:35   4102432
> >>   3.1.20020425+kurt-finl.  4:32   3912640  <-- this is with the patch
> > This is with both patches I assume.
> 
> No, the first one is just your v3 patch, and the second one just the
> finline patch.

Oh well, then the better build time and binary size is not so astonishing.
At least if you compile with -O3 (or -O2 -finline-functions).

Because the main thing the patch does is memorize whether a function was
inlined by the keyword or by the -finline-functions option. The latter
only get half the allowable size, so we do less inlining and thus have
shorter compile times and binary sizes.

Actually, if I compare the finline patch results to plain 3.1, the results
are not so bad. I compared to -v3.

For my own benchmarks, I do see best performance with gcc-3.1 with -v3
patch and the options -O3 -fno-inline-functions.
If I use -O3, performance drops by 5--10%. With the finline patch (on top of
the -v3 patch), I do see only a small drop for using -O3. But unfortunately, 
I also see a very small drop with -O3 -fno-inline-functions as compared to
plain -v3, and I don't quite understand why. 
Maybe a function that is implicitly declared inline by being defined in the
class declaration is marked automatically inlined in decl.c, so we limit the
inliner on those as well? I'll try to find out ...

> > I'm astonished we beat plain 0422 at build time and binary size.

I'm not any more.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security