From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20284 invoked by alias); 25 Apr 2002 22:23:04 -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 20277 invoked from network); 25 Apr 2002 22:23:02 -0000 Received: from unknown (HELO etpmod.phys.tue.nl) (131.155.111.35) by sources.redhat.com with SMTP; 25 Apr 2002 22:23:02 -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 AAA02765; Fri, 26 Apr 2002 00:23:01 +0200 Received: (from garloff@localhost) by gum01m.etpnet.phys.tue.nl (8.11.6/8.11.6/SuSE Linux 0.5) id g3PMN1x15576; Fri, 26 Apr 2002 00:23:01 +0200 Date: Thu, 25 Apr 2002 15:30:00 -0000 From: Kurt Garloff To: Gerald Pfeifer Cc: gcc@gcc.gnu.org, Andreas Jaeger Subject: Re: inliner in gcc-3.1 Message-ID: <20020426002301.C14090@gum01m.etpnet.phys.tue.nl> References: <20020424132314.B27120@gum01m.etpnet.phys.tue.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hOcCNbCCxyk/YU74" 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/msg01354.txt.bz2 --hOcCNbCCxyk/YU74 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3079 Hi Gerald, thanks for testing! On Thu, Apr 25, 2002 at 06:36:10PM +0200, Gerald Pfeifer wrote: > On Wed, 24 Apr 2002, Kurt Garloff wrote: > > It would be nice if this patch > > http://www.garloff.de/kurt/freesoft/gcc/gcc310-inline-func-acct-v1.diff > > would be tested by more people and integrated into 3.1. >=20 > This second patch (partially) fixes a very bad regression we've been > having since GCC 3.0; build time and binary size seem to be fine, though > we seem to degrade slightly for some of the other benchmarks. >=20 > I'd really like to see what this does to SPEC -- Andreas, could you give > it a try? Actually, maybe we should wait a second. When I developed the patch on 3.0.1, I was not seeing the degradation you see now for some benchmarks. So I must have done some mistake when porting it from 3.0.1 to 3.1, or some assumption I made is not true any more. I've done some more benchmarks with this inline accounting patch and I also have found a case with performance regression against v3, even without -finline-functions, so something must have gone wrong I think. What I try to do in the patch is to improve -O3 (-finline-functions) performance. The idea is to keep the information whether a function was declared inline or whether it got inlined by virtue of the automatic inlining. I may have screwed this up ... and set the flag when it should not, so we actually treat the inline declared function with the=20 lower automatic limit. (a) The declared inline fn would get the full 300/600 limit whereas the automatically inlined ones only half. [The idea is that we still think the programmer has a bit of a clue. Maybe the factor 0.5 is a bit too strict.] The patch also does two other things that have proven useful on 2.95.3 (b) better tune -Os (again tested on i386) (c) give leaf functions a bonus (*3/2) in the RTL inliner [is it still used at all?] Maybe one should separate those issues and verify that do what my intention was. I would certainly appreciate if somebody with some more knowledge of the compiler internals would have a look. Any takers? > (This is due to a C module in the C++ application, and your fix seems > to be critical for many C applications in general.) >=20 > 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. I'm astonished we beat plain 0422 at build time and binary size. But the benchmark results do not really look attractive to me. We only=20 win one benchmark against -v3, and even against plain we sometimes lose. Regards, --=20 Kurt Garloff Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE Linux AG, Nuernberg, DE SCSI, Security --hOcCNbCCxyk/YU74 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 iD8DBQE8yIHExmLh6hyYd04RAsM0AKCepd4BRPRIUbDUZniBWxAOSjEpUwCfZ0eD ku73QQe8ExtJcBwWIbVDZ0s= =v0SU -----END PGP SIGNATURE----- --hOcCNbCCxyk/YU74--