On Jan 5, 2008 6:43 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] 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.
