From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6337 invoked by alias); 4 Aug 2003 17:54:36 -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 6313 invoked from network); 4 Aug 2003 17:54:35 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.54) by sources.redhat.com with SMTP; 4 Aug 2003 17:54:35 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id SAA02911; Mon, 4 Aug 2003 18:54:27 +0100 (BST) Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id h74HsRP03291; Mon, 4 Aug 2003 18:54:27 +0100 Message-Id: <200308041754.h74HsRP03291@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Joe Buck cc: Robert Dewar , aoliva@redhat.com, bernds@redhat.com, gcc@gcc.gnu.org, gdr@integrable-solutions.net, rguenth@tat.physik.uni-tuebingen.de, s.bosscher@student.tudelft.nl, Richard.Earnshaw@arm.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: std::pow implementation In-reply-to: Your message of "Mon, 04 Aug 2003 10:19:37 PDT." <20030804101937.H24974@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Aug 2003 18:05:00 -0000 From: Richard Earnshaw X-SW-Source: 2003-08/txt/msg00178.txt.bz2 > > > (*) Reasons why I'd accept inline not being honoured: > > On Mon, Aug 04, 2003 at 12:53:09PM -0400, Robert Dewar wrote: > > I would add > > > > - doing the inlining as requested increases both the space and execution time > > of the program, the former very substantially. > > Nope. It is appropriate for the compiler to do what the user said. In > C++, inline functions are for the most part so tiny that the inlined > function takes up less space than the call. Having the compiler compute > metrics for all these functions in an effort to second-guess the > programmer only slows the compiler down. Not necessarily. The benefit might be more than repaid in terms of less time spent in CSE if the function turned out to be large. > If the user asks for very large functions to be inlined, the user loses. > But the good news is that the fix is easy. Think portability. Having to change the code every time you compile on a different platform breaks the whole concept of using high-level languages to get away from the machine abstraction. The issue here isn't what to do with really tiny functions, or even what to to with really enormous ones: it's entirely to do with the boundary between the two -- how does the compiler decide that it has crossed from one to the other? A smart compiler can work that out based on its knowledge of the machine. A dumb one can't. Do we want gcc to be smart or dumb? R.