Re: __builtin_expect for indirect function calls

["Richard Guenther" <richard.guenther@gmail.com>]

On Jan 5, 2008 6:43 AM, Mark Mitchell <mark@codesourcery.com> wrote:
> 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...?

I think we should simply make __builtin_expect polymorphic, but make sure
to promote integral arguments with rank less than long to long.

Richard.