From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6061 invoked by alias); 4 Aug 2003 17:03:24 -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 6028 invoked from network); 4 Aug 2003 17:03:21 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 4 Aug 2003 17:03:21 -0000 Received: from free.redhat.lsd.ic.unicamp.br (aoliva.cipe.redhat.com [10.0.1.10]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h74H3IK03211; Mon, 4 Aug 2003 13:03:18 -0400 Received: from free.redhat.lsd.ic.unicamp.br (free.redhat.lsd.ic.unicamp.br [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.9/8.12.9) with ESMTP id h74H3HXH018352; Mon, 4 Aug 2003 14:03:17 -0300 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.9/8.12.9/Submit) id h74H39mN018348; Mon, 4 Aug 2003 14:03:09 -0300 To: Bernd Schmidt Cc: Gabriel Dos Reis , Steven Bosscher , Richard Guenther , gcc@gcc.gnu.org Subject: Re: std::pow implementation References: <1059481647.3651.120.camel@steven.lr-s.tudelft.nl> <1059483328.3651.144.camel@steven.lr-s.tudelft.nl> <1059487859.3650.208.camel@steven.lr-s.tudelft.nl> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Mon, 04 Aug 2003 17:08:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-08/txt/msg00145.txt.bz2 On Aug 4, 2003, Bernd Schmidt wrote: > We've had -finline-functions (aka -O3) for years; it does what you > suggest: let the compiler choose which functions to inline. If we > assume that this option does a reasonable job, it can be used if you > want to write portable code and don't want to bother with performance > measurements and suchlike. I'd promised I'd step away from the debate, but my argument is being misunderstood, so I'll just clarify. I'm not arguing for the compiler to disregard inline entirely, in that, if you don't mark a function as candidate for inlining, the compiler won't even consider the possibility of inlining. However, if you do, it will evaluate whether it appears to make sense to inline it in order to improve performance, or whether the inline marker was there just to make the body of the function visible for the translation unit, in case inlining was found to be profitable. Unfortunately, the only way to make the body visible without violating the ODR is by marking the function as inline, either with the inline keyword or by defining it inside the class body. > I propose that it have the effect expected by most people who aren't > compiler hackers: let the function be inlined, if possible within > reasonable limits (*). We agree here. The trick is to define what reasonable limits are. Not everybody agrees that it's reasonable to get compile time or generated code size to explode even if the program would still work. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer