Re: __builtin_expect for indirect function calls

[Mark Mitchell <mark at codesourcery dot com>]

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