From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18126 invoked by alias); 30 Jul 2003 10:37:06 -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 18112 invoked from network); 30 Jul 2003 10:37:05 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.54) by sources.redhat.com with SMTP; 30 Jul 2003 10:37:05 -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 LAA07245; Wed, 30 Jul 2003 11:37:03 +0100 (BST) Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id h6UAb3P18424; Wed, 30 Jul 2003 11:37:03 +0100 Message-Id: <200307301037.h6UAb3P18424@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Gabriel Dos Reis cc: Alexandre Oliva , Richard Guenther , gcc@gcc.gnu.org, 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 "30 Jul 2003 08:31:07 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Jul 2003 11:58:00 -0000 From: Richard Earnshaw X-SW-Source: 2003-07/txt/msg02126.txt.bz2 > Alexandre Oliva writes: > > | On Jul 30, 2003, Gabriel Dos Reis wrote: > | > | > If you give inline its original meaning, you won't run into the risk > | > of the situation you're describing. > | > | Which meaning are you talking about? > > The meaning of "inline" when it was originally introduced in C++. I'm > quoting here "The Design and Evolution of C++" (also part of an > article I intented to send to a broader audience), section "Run-Time > Efficiency": > > The general reason for the introduction of inline functions was > concern that the cost of crossing a protection barrier would cause > people to refrain from using classes to hide representation. In > particular [Stroustrup, 1982b] observes that people had made data > members public to avoid the function call overhead incurred by a > constructor for simple classes where only one or two assignments are > needed for initialization. The immediate cause for the inclusion of > inline functions into C with Classes was a project that couldn't > afford function call overhead for some classes involved in real-time > processing. For classes to be useful in that application, crossing > the protection barrier had to be free. > 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. > [...] > > 2.4.1 Inlining > > Inlining was considered important for the utility of classes. > Therefore, the issue was more /how/ to provide it than /whether/ to > provide it. Two arguments won the day for the notion of having the > programmer select which functions the compiler should try to inline. Note the word "try" in the line above. > First, I had poor experiences with languages that left the job of > inlining to compilers "because clearly the compiler knows best." > The compiler only knows best if it has been programmed to inline and > it has a notion of time/space optimization that agrees with mine. My > experience with other languages was that only "the next release" > would actually inline, and it would do so according to an internal > logic that a programmer couldn't effectively control. [...] > Furthermore, techniques that require global analysis, such as > automatic inlining without user support, tend not to scale well to > very large programs. C with Classes was designed to deliver > efficient code given a simple, portable implementation on > traditional systems. Given that, the programmer had to help. Even > today, the choice seems right. > > > Reference [Stroustrup, 1982b] is > Bjarne Stroustrup: "Adding Classes to C: An Exercise in Language > Evolution". Bell Laboratories Compuer Science > internal document. April 1982. > Software: Practice & Experience, Vol 13. 1983 > > > Never forget that inlining is a *key* feature for the effective use > and utsefulness of classes. Not disputed. > "Inline" was introduced to give control > to the programmer. 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 and we can spend as much time as we want disputing whether the compiler has reached that standard; however, to reach it does not necessarily have to mean that it conceptually substitutes every statement from the body of an "inline" function into the caller. Careful use of inline by the programmer will aid the compiler in achieving that goal. R.