This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: __builtin_expect for indirect function calls
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: mendell@ca.ibm.com
From: Mark Mitchell <mark@codesourcery.com>
To: Richard Guenther <richard.guenther@gmail.com>
Cc: trevor_smigiel@playstation.sony.com, Hans-Peter Nilsson <hp@bitrange.com>, gcc <gcc@gcc.gnu.org>,
Russell_Olsen@playstation.sony.com, Andrew_Pinski@playstation.sony.com, Mark Mendell/Toronto/IBM@IBMCA
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
mark@codesourcery.com
(650) 331-3385 x713