From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-80134-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 742 invoked by alias); 30 Jul 2003 14:26:27 -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 364 invoked from network); 30 Jul 2003 14:26:15 -0000
Received: from unknown (HELO mailout01.sul.t-online.com) (194.25.134.80)
  by sources.redhat.com with SMTP; 30 Jul 2003 14:26:15 -0000
Received: from fwd10.aul.t-online.de 
	by mailout01.sul.t-online.com with smtp 
	id 19hrtu-0004jz-09; Wed, 30 Jul 2003 16:25:58 +0200
Received: from kolme (bHQAm2ZCwergxg8OQ7khdxva3Z4yaWaz3ZBKcZQMfJzc65BI5iGzc+@[80.138.148.130]) by fmrl10.sul.t-online.com
	with esmtp id 19hrtk-0kPxrc0; Wed, 30 Jul 2003 16:25:48 +0200
Received: from goofy.hamnixda.de ([192.168.100.249] helo=goofy)
	by kolme with esmtp (Exim 3.35 #1 (Debian))
	id 19hrth-0000X3-00; Wed, 30 Jul 2003 16:25:45 +0200
Received: from richard (helo=localhost)
	by goofy with local-esmtp (Exim 3.36 #1 (Debian))
	id 19hrti-0000R5-00; Wed, 30 Jul 2003 16:25:46 +0200
Date: Wed, 30 Jul 2003 14:48: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: <m3fzko3y1o.fsf@uniton.integrable-solutions.net>
Message-ID: <Pine.LNX.4.44.0307301624400.561-100000@goofy>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Seen: false
X-ID: bHQAm2ZCwergxg8OQ7khdxva3Z4yaWaz3ZBKcZQMfJzc65BI5iGzc+@t-dialin.net
X-SW-Source: 2003-07/txt/msg02184.txt.bz2

> | 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).

Richard.