From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-80125-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 15042 invoked by alias); 30 Jul 2003 14:11:13 -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 14986 invoked from network); 30 Jul 2003 14:11:12 -0000
Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186)
  by sources.redhat.com with SMTP; 30 Jul 2003 14:11:12 -0000
Received: from uniton.integrable-solutions.net (localhost [127.0.0.1])
	by uniton.integrable-solutions.net (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h6UEAiSu021828;
	Wed, 30 Jul 2003 16:10:44 +0200
Received: (from gdr@localhost)
	by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id h6UEAhTb021827;
	Wed, 30 Jul 2003 16:10:43 +0200
X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f
To: Richard Guenther <rguenth@tat.physik.uni-tuebingen.de>
Cc: Richard.Earnshaw@arm.com, Karel Gardas <kgardas@objectsecurity.com>,
   Alexandre Oliva <aoliva@redhat.com>, <gcc@gcc.gnu.org>
Subject: Re: std::pow implementation
References: <Pine.LNX.4.44.0307301553090.561-100000@goofy>
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
In-Reply-To: <Pine.LNX.4.44.0307301553090.561-100000@goofy>
Organization: Integrable Solutions
Date: Wed, 30 Jul 2003 14:24:00 -0000
Message-ID: <m3fzko3y1o.fsf@uniton.integrable-solutions.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2003-07/txt/msg02175.txt.bz2

Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> writes:

| On 30 Jul 2003, Gabriel Dos Reis wrote:
| 
| > Richard Earnshaw <rearnsha@arm.com> writes:
| >
| > | > Richard Earnshaw <rearnsha@arm.com> writes:
| > | >
| > | > [...]
| > | >
| > | > | Now, assume that the amount of code in the a!=1 case is reduced.  At what
| > | > | point does it become beneficial to always inline?  Can the programmer
| > | > | tell?
| > | >
| > | > He can profile.
| > |
| > | Profiling doesn't help if the answer comes back as "sometimes" (function
| > | foo's use of bar is best inlined, function wibble's use of bar is best not
| > | inlined).
| >
| > The cases where it most does not help is when the compiler decides it
| > knows better and goes on using his own programmed logic.
| 
| Oh - I thought you meant profile directed inlining decisions by the
| compiler, not by the user. The latter is not useful.

I'm not excluding profile directed inlining. But we don't have
architecture in place for that yet.

[...]

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

-- Gaby