From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12667 invoked by alias); 5 Aug 2003 07:44:08 -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 12376 invoked from network); 5 Aug 2003 07:43:42 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 5 Aug 2003 07:43:42 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h757heZ03635; Tue, 5 Aug 2003 03:43:40 -0400 Received: from talisman.cambridge.redhat.com (talisman.cambridge.redhat.com [172.16.18.81]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h757hbI29561; Tue, 5 Aug 2003 03:43:37 -0400 Received: (from rsandifo@localhost) by talisman.cambridge.redhat.com (8.11.6/8.11.6) id h757ddx26997; Tue, 5 Aug 2003 08:39:39 +0100 To: dewar@gnat.com (Robert Dewar) Cc: gdr@integrable-solutions.net, jbuck@synopsys.com, gcc@gcc.gnu.org Subject: Re: On inlining in C++ References: <20030804163548.93772F2D7E@nile.gnat.com> From: Richard Sandiford Date: Tue, 05 Aug 2003 08:26:00 -0000 In-Reply-To: <20030804163548.93772F2D7E@nile.gnat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-08/txt/msg00256.txt.bz2 dewar@gnat.com (Robert Dewar) writes: > > Excellent article. I think that anyone who wishes to oppose the argument > > should be asked to demonstrate that we can get better quality of results > > by deviating from the simple approach Gaby describes; philosophical > > arguments should not suffice. > > Well there is a burden of demonstration on both sides I would say, in terms > of showing behavior on actual code. I'd have thought the burden was (almost entirely) on the people defending g++'s current behaviour. Suppose that, as an experiment, someone changes g++ to interpret inline in the "traditional"[*] way. And then someone shows that this leads to worse performance for program X on target Y. I don't think we can then say that the compiler is right to behave is it does now. Perhaps whoever wrote program X didn't care about the performance on target Y, or perhaps s/he simply used "inline" poorly. Both are possible, and it's not the sort of thing you're going to get from a simple statistical analysis (said in response to: "we need more data", from another message). So (IMO) if g++ is going to ignore inline requests for "inlineable" functions, the data in favour of that should be overwhelming. It's a bit worrying that g++ is already doing this and that no-one seems to have a large body of existing data to justify it. Even if we change gcc in the way that Gaby suggests, we could still provide the existing behaviour as a flag. A sort of restricted -finline-functions. It's not like we have to lose the existing behaviour entirely. Richard PS. OK, so "principle of least surprise" was shorter ;) [*] the one that Gaby quoted.