From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-80140-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 19196 invoked by alias); 30 Jul 2003 14:44:56 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 19156 invoked from network); 30 Jul 2003 14:44:41 -0000
Received: from unknown (HELO mailout04.sul.t-online.com) (194.25.134.18)
  by sources.redhat.com with SMTP; 30 Jul 2003 14:44:41 -0000
Received: from fwd04.aul.t-online.de 
	by mailout04.sul.t-online.com with smtp 
	id 19hsBt-0004fc-01; Wed, 30 Jul 2003 16:44:33 +0200
Received: from kolme (XpmrloZTgec6ODVgXapff1kYlBewH0PGzWBODSd9JlRHLF3BGHfk4M@[80.138.148.130]) by fmrl04.sul.t-online.com
	with esmtp id 19hsBk-0xgA640; Wed, 30 Jul 2003 16:44:24 +0200
Received: from goofy.hamnixda.de ([192.168.100.249] helo=goofy)
	by kolme with esmtp (Exim 3.35 #1 (Debian))
	id 19hsBh-0000XD-00; Wed, 30 Jul 2003 16:44:21 +0200
Received: from richard (helo=localhost)
	by goofy with local-esmtp (Exim 3.36 #1 (Debian))
	id 19hsBj-0000SO-00; Wed, 30 Jul 2003 16:44:23 +0200
Date: Wed, 30 Jul 2003 15:29:00 -0000
From: Richard Guenther <rguenth@tat.physik.uni-tuebingen.de>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
cc: Richard.Earnshaw@arm.com, Karel Gardas <kgardas@objectsecurity.com>, 
    Alexandre Oliva <aoliva@redhat.com>,  <gcc@gcc.gnu.org>
Subject: Re: std::pow implementation
In-Reply-To: <m3n0ew2ii4.fsf@uniton.integrable-solutions.net>
Message-ID: <Pine.LNX.4.44.0307301642020.561-100000@goofy>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Seen: false
X-ID: XpmrloZTgec6ODVgXapff1kYlBewH0PGzWBODSd9JlRHLF3BGHfk4M@t-dialin.net
X-SW-Source: 2003-07/txt/msg02190.txt.bz2

On 30 Jul 2003, Gabriel Dos Reis wrote:

> Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> writes:
>
> | > | 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'm arguing for #1 and #3 combined.  Meaning, inline simple functions
> | > at low optimization level, try hard at higher level + compiler
> | > parameter adjustement.
> |
> | Thats what we have now - generally we go with #3, for small functions we
> | go with #1 (tune what is small with --param min-inline-insns=XXX).
>
> What I'm arguing for is not what have.  For example, something like
> 'std::string() const' does not need fiddling with --param -- that is,
> its inlining should not depend on the context of use.

Its inlining doesnt depend on the context of use if it is small enough. Of
course now we are at the point where the compiler needs to decide how
large a function is - and this area vastly improved a few weeks ago. If
this is still not your point you need to start defining what a "small"
function is. Apart from being a function whose inlining is profitable, of
course ;)

Richard.