From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31570 invoked by alias); 30 Jul 2003 13:59:47 -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 31315 invoked from network); 30 Jul 2003 13:59:35 -0000 Received: from unknown (HELO mailout05.sul.t-online.com) (194.25.134.82) by sources.redhat.com with SMTP; 30 Jul 2003 13:59:35 -0000 Received: from fwd08.aul.t-online.de by mailout05.sul.t-online.com with smtp id 19hrTz-0002WV-0D; Wed, 30 Jul 2003 15:59:11 +0200 Received: from kolme (EkKgDZZEQe7E+V+gW1jPTPhImytka0x6OUfONmVGSRaB7FVS4PdeY8@[80.138.148.130]) by fmrl08.sul.t-online.com with esmtp id 19hrTu-1cl34q0; Wed, 30 Jul 2003 15:59:06 +0200 Received: from goofy.hamnixda.de ([192.168.100.249] helo=goofy) by kolme with esmtp (Exim 3.35 #1 (Debian)) id 19hrTr-0000W1-00; Wed, 30 Jul 2003 15:59:04 +0200 Received: from richard (helo=localhost) by goofy with local-esmtp (Exim 3.36 #1 (Debian)) id 19hrTs-0000O7-00; Wed, 30 Jul 2003 15:59:04 +0200 Date: Wed, 30 Jul 2003 14:08:00 -0000 From: Richard Guenther To: Gabriel Dos Reis cc: Richard.Earnshaw@arm.com, Karel Gardas , Alexandre Oliva , Richard Guenther , Subject: Re: std::pow implementation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Seen: false X-ID: EkKgDZZEQe7E+V+gW1jPTPhImytka0x6OUfONmVGSRaB7FVS4PdeY8@t-dialin.net X-SW-Source: 2003-07/txt/msg02166.txt.bz2 On 30 Jul 2003, Gabriel Dos Reis wrote: > Richard Earnshaw writes: > > | > Richard Earnshaw writes: > | > > | > [...] > | > > | > | Now, assume that the amount of code in the a!=1 case is reduced. At what > | > | point does it become beneficial to always inline? Can the programmer > | > | tell? > | > > | > He can profile. > | > | Profiling doesn't help if the answer comes back as "sometimes" (function > | foo's use of bar is best inlined, function wibble's use of bar is best not > | inlined). > > The cases where it most does not help is when the compiler decides it > knows better and goes on using his own programmed logic. Oh - I thought you meant profile directed inlining decisions by the compiler, not by the user. The latter is not useful. > | > | With Gaby's suggested interpretation, the compiler has *no* choice; it > | > | must obey the inlining constraint because the programmer always knows > | > | better... Even when prepared to admit that he doesn't. > | > > | > That assertion is wrong. > | > | Which bit of it? It's what I understand you to be suggesting. > > As I've repeatedly said, there are pathological cases where the > compiler simply cannot inline. Secondly, I'm saying that the > compiler does not always know better than the programmer. And in fact, > the programmer most of the time declares "inline" on purpose. > > Transmuting the meaning of "inline" is creating more fear, uncertainty > and doubt than we needed. So what are the semantics of the "inline" keyword you propose? What I read into your statements is something like "the compiler should inline a function if I want it to be inline, and he should read my mind for deciding this." The only sane possible semantics I see are: 1. inline declared functions are inlined always if technically possible 2. the inline keyword has no effect 3. inline is handled in an implementation defined manner (as stated in the standard), maybe by adjusting the set of functions considered for inlining, as gcc does. I argue we cannot go away from #3 without portability problems (to other compilers and architectures). Richard.