From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4957 invoked by alias); 30 Jul 2003 16:29: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 4765 invoked from network); 30 Jul 2003 16:29:29 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.54) by sources.redhat.com with SMTP; 30 Jul 2003 16:29:29 -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 RAA07478; Wed, 30 Jul 2003 17:29:11 +0100 (BST) Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id h6UGTBk21027; Wed, 30 Jul 2003 17:29:11 +0100 Message-Id: <200307301629.h6UGTBk21027@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Scott Robert Ladd cc: Richard.Earnshaw@arm.com, Gabriel Dos Reis , Alexandre Oliva , Richard Guenther , gcc@gcc.gnu.org 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 "Wed, 30 Jul 2003 11:26:10 EDT." <3F27E392.2080504@coyotegulch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Jul 2003 16:50:00 -0000 From: Richard Earnshaw X-SW-Source: 2003-07/txt/msg02218.txt.bz2 > Richard Earnshaw wrote: > > This is talking specifically about *very small* functions ("one or two > > assignments"). It says nothing about what happens if the programmer > > decides to put a 2000 line monstrosity in the middle of a class definition > > (which would be legal, if somewhat stupid). A practical compiler > > eventually has to say "enough is enough", or it is likely to crash, run > > out of memory or whatever. > > I do not want my freedom limited by the stupidity of others. If someone > explicitly inlines a 2000-line function, let them; the wisdom of such a > choice (or lack thereof) is an issue for code review and the marketplace. > > Let's say that I use a little shell sort in a program; should the > compiler decide to replace my explicit choice of algorithm with > quicksort, even though I have determined that shell sort is better? > > When I say "inline", I mean inline, regardless of other opinions > (including those of the compiler). Really? And when you say "register" do you really mean that? If so, then I'm sorry, but you are in for a big disappointment when using gcc -- it completely ignores the register keyword when optimizing and has done since ~forever. > > > I disagree. What really counts is that the compiler has sufficient > > information to do a good job when compiling the code (ie to reduce, and > > hopefully eliminate, the abstraction penalty). What constitutes a "good > > job" is up to the compiler... > > No. > > What constitutes a "good job" is defined by a human mind, not a piece of > technology that lacks any concept of "good." Over the years, I've found > many arrogant tools (and not just from Microsoft) -- tools that assume, > *incorrectly*, that their "wisdom" exceeds mine. > I've already given examples of when the compiler can make use of context to give better inlining than can be determined statically. Your "arrogant" assertion that inline must always and unconditionally mean inline impliess that programmers can never take advantage of those cases. R.