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 <[EMAIL PROTECTED]> [2008-01-03 12:12]:
> Hans-Peter Nilsson wrote:
> > On Mon, 17 Dec 2007, [EMAIL PROTECTED] 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
> [EMAIL PROTECTED]
> (650) 331-3385 x713
