From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14533 invoked by alias); 3 Jan 2008 23:36:27 -0000 Received: (qmail 14524 invoked by uid 22791); 3 Jan 2008 23:36:25 -0000 X-Spam-Check-By: sourceware.org Received: from outbound-va3.frontbridge.com (HELO outbound4-va3-R.bigfish.com) (216.32.180.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Jan 2008 23:33:14 +0000 Received: from outbound4-va3.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound4-va3-R.bigfish.com (Postfix) with ESMTP id 935F3167A822; Thu, 3 Jan 2008 23:33:12 +0000 (UTC) Received: from mail10-va3-R.bigfish.com (si1-va3 [10.7.14.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by outbound4-va3.bigfish.com (Postfix) with ESMTP id 881181138067; Thu, 3 Jan 2008 23:33:12 +0000 (UTC) Received: from mail10-va3 (localhost.localdomain [127.0.0.1]) by mail10-va3-R.bigfish.com (Postfix) with ESMTP id 7164B3103A1; Thu, 3 Jan 2008 23:33:12 +0000 (UTC) X-BigFish: V X-MS-Exchange-Organization-Antispam-Report: OrigIP: 160.33.98.75;Service: EHS Received: by mail10-va3 (MessageSwitch) id 1199403192410809_24150; Thu, 3 Jan 2008 23:33:12 +0000 (UCT) Received: from mail8.fw-bc.sony.com (mail8.fw-bc.sony.com [160.33.98.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail10-va3.bigfish.com (Postfix) with ESMTP id 5834A1A78054; Thu, 3 Jan 2008 23:33:12 +0000 (UTC) Received: from mail3.sjc.in.sel.sony.com (mail3.sjc.in.sel.sony.com [43.134.1.211]) by mail8.fw-bc.sony.com (8.12.11/8.12.11) with ESMTP id m03NXBtx021796; Thu, 3 Jan 2008 23:33:11 GMT Received: from constantine.playstation.sony.com ([162.49.67.15]) by mail3.sjc.in.sel.sony.com (8.12.11/8.12.11) with ESMTP id m03NXA2v016258; Thu, 3 Jan 2008 23:33:10 GMT Received: from deagol.playstation.sony.com ([10.98.10.144]) by constantine.playstation.sony.com (Lotus Domino Release 7.0.2FP2) with ESMTP id 2008010315330868-1196 ; Thu, 3 Jan 2008 15:33:08 -0800 Received: from trevor by deagol.playstation.sony.com with local (Exim 3.36 #1 (Debian)) id 1JAZYi-0003BO-00; Thu, 03 Jan 2008 15:33:08 -0800 Date: Thu, 03 Jan 2008 23:36:00 -0000 To: Mark Mitchell Cc: Hans-Peter Nilsson , gcc , Russell_Olsen@playstation.sony.com, Andrew_Pinski@PlayStation.Sony.Com, Mark Mendell Subject: Re: __builtin_expect for indirect function calls Message-ID: <20080103233308.GD5853@playstation.sony.com> References: <20071218000552.GV3656@playstation.sony.com> <20071221220630.Y67443@dair.pair.com> <4772A350.6030907@codesourcery.com> MIME-Version: 1.0 In-Reply-To: <4772A350.6030907@codesourcery.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: trevor_smigiel@playstation.sony.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00030.txt.bz2 If possible, I agree it seems natural to extend __builtin_expect. My concern would be backwards compatibility. Currently, the prototype for __builtin_expect is long __builtin_expect (long expression, long constant); Extending it to functions would change it to T __builtin_expect (T expression, T expected); With these additional semantics and restrictions: - when the return value is being used as a call expression: * T is the type of 'expression' * 'expected' is allowed to be a non-constant - when the return value is not being used as a call expression: * T is type 'long; * 'expected' must be a compile-time constant Given the above definition, I don't think there is any backwards compatibility issues because we are inspecting the context of the use of __builtin_expect. Rather than the above definition, we could choose not to inspect the context and just say: * T is the type of 'expression' * 'expected' is allowed to be a non-constant In this case I think there would only be compatibility issues with unusual uses of __builtin_expect, for example, if it was being used in a function argument and its type effected overload resolution. Or if the argument was a float and was being implicitly converted to a long (with a warning). There would also be code which previously gave warnings but does not with the extended __builtin_expect. I'm ok with either of these definitions, if extending __builtin_expect is the preferred way to go. Are either of these definitions ok? Or are there other ideas how to define it? Trevor * Mark Mitchell [2008-01-03 12:12]: > Hans-Peter Nilsson wrote: > > On Mon, 17 Dec 2007, trevor_smigiel@playstation.sony.com wrote: > >> When we can't hint the real target, we want to hint the most common > >> target. There are potentially clever ways for the compiler to do this > >> automatically, but I'm most interested in giving the user some way to do > >> it explicitly. One possiblity is to have something similar to > >> __builtin_expect, but for functions. For example, I propose: > >> > >> __builtin_expect_call (FP, PFP) > > > > Is there a hidden benefit? I mean, isn't this really > > expressable using builtin_expect as-is, at least when it comes > > to the syntax? > > That was my first thought as well. Before we add __builtin_expect_call, > I think there needs to be a justification of why this can't be done with > __builtin_expect as-is. > > -- > Mark Mitchell > CodeSourcery > mark@codesourcery.com > (650) 331-3385 x713