From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21632 invoked by alias); 5 Jan 2008 05:44:10 -0000 Received: (qmail 21619 invoked by uid 22791); 5 Jan 2008 05:44:09 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 05 Jan 2008 05:43:52 +0000 Received: (qmail 5758 invoked from network); 5 Jan 2008 05:43:49 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Jan 2008 05:43:49 -0000 Message-ID: <477F190B.2000807@codesourcery.com> Date: Sat, 05 Jan 2008 05:44:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: trevor_smigiel@playstation.sony.com 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 References: <20071218000552.GV3656@playstation.sony.com> <20071221220630.Y67443@dair.pair.com> <4772A350.6030907@codesourcery.com> <20080103233308.GD5853@playstation.sony.com> In-Reply-To: <20080103233308.GD5853@playstation.sony.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00040.txt.bz2 trevor_smigiel@playstation.sony.com wrote: > 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); Yes, it really makes more sense for __builtin_expect to be polymorphic in this way anyhow. I consider it a design wart that it's defined in terms of "long". (For example, this means you can't use it for "long long"!) > 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. I think this is the abstractly right approach. However, you're right that there are backwards-compatibility issues. Another issue is that on platforms where "long" and "int" do not have the same width, something like: sizeof(__builtin_expect(1, 1)) will change its value. And, the current prototype is documented in the manual. What do people think? Do we have the leeway to change this? Or should we add __builtin_expect2? Or add an -fno-polymorphic-builtin-expect? Or...? Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713