The frontends here would prefer to just implement __builtin_expect_call
(fp,foo), and leave __builtin_expect as it is now. We don't see a need for
a polymorphic __builtin_expect, as we are worried about backwards
compatibility.
A question was raised: Are side effects in the second parameter guaranteed
to be executed? Is it valid for a compiler to ignore any side effects?
Mark Mendell
TOBEY Team Lead
IBM Toronto Laboratory, 8200 Warden Ave, Markham, Ontario, Canada, L6G 1C7
Tel: 905-413-3485 Tie: 313-3485 Internet: [EMAIL PROTECTED]
From: Mark Mitchell <[EMAIL PROTECTED]>
To: Richard Guenther <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], Hans-Peter Nilsson <[EMAIL PROTECTED]>, gcc
<gcc@gcc.gnu.org>,
[EMAIL PROTECTED], [EMAIL PROTECTED], Mark Mendell/Toronto/[EMAIL
PROTECTED]
Date: 06/01/2008 02:42 PM
Subject: Re: __builtin_expect for indirect function calls
Richard Guenther wrote:
>> 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.
I thought of that, but I hadn't suggested this idea because it seemed so
weird. Promoting to int would not be odd, but promoting to long is
weird. Anyhow, you're right; that's another option, and, despite
weirdness, plausible. I can't think of a way in which it changes
current behavior, unless you call __builtin_expect with a long long, and
that's probably not going to do what you expect right now anyhow.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
