Re: __builtin_expect for indirect function calls

[trevor_smigiel@playstation.sony.com]

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 <mark@codesourcery.com> [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