From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17487 invoked by alias); 26 Apr 2002 15:20:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 17284 invoked from network); 26 Apr 2002 15:20:18 -0000 Received: from unknown (HELO etpmod.phys.tue.nl) (131.155.111.35) by sources.redhat.com with SMTP; 26 Apr 2002 15:20:18 -0000 Received: from gum01m.etpnet.phys.tue.nl (gum01m.etpnet.phys.tue.nl [192.168.84.65]) by etpmod.phys.tue.nl (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA28202; Fri, 26 Apr 2002 17:20:16 +0200 Received: (from garloff@localhost) by gum01m.etpnet.phys.tue.nl (8.11.6/8.11.6/SuSE Linux 0.5) id g3QFKGJ20786; Fri, 26 Apr 2002 17:20:16 +0200 Date: Fri, 26 Apr 2002 08:20:00 -0000 From: Kurt Garloff To: Gerald Pfeifer Cc: gcc@gcc.gnu.org, Andreas Jaeger Subject: Re: inliner in gcc-3.1 Message-ID: <20020426172016.A20666@gum01m.etpnet.phys.tue.nl> References: <20020426002301.C14090@gum01m.etpnet.phys.tue.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-Operating-System: Linux 2.4.16-schedJ2 i686 X-PGP-Info: on http://www.garloff.de/kurt/mykeys.pgp X-PGP-Key: 1024D/1C98774E, 1024R/CEFC9215 Organization: TU/e(NL), SuSE(DE) X-SW-Source: 2002-04/txt/msg01410.txt.bz2 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2295 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. >=20 > 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. >=20 > 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= ,=20 I also see a very small drop with -O3 -fno-inline-functions as compared to plain -v3, and I don't quite understand why.=20 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, --=20 Kurt Garloff Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE Linux AG, Nuernberg, DE SCSI, Security --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline Content-length: 232 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8yXAwxmLh6hyYd04RAmxcAKC+JD4c7y9f5z8G3wOuf1RVxv16AgCdE5J7 gKrqO1d1H+iWAQRm3ZpDAtI= =fR/6 -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC--