This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] malloc: remove __builtin_expect
- From: Florian Weimer <fweimer at redhat dot com>
- To: munroesj at linux dot vnet dot ibm dot com, Yury Gribov <y dot gribov at samsung dot com>
- Cc: Joern Engel <joern at purestorage dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, Joern Engel <joern at purestorage dot org>
- Date: Tue, 26 Jan 2016 22:07:52 +0100
- Subject: Re: [PATCH] malloc: remove __builtin_expect
- Authentication-results: sourceware.org; auth=none
- References: <1453767942-19369-1-git-send-email-joern at purestorage dot com> <1453767942-19369-21-git-send-email-joern at purestorage dot com> <56A726C1 dot 6070206 at samsung dot com> <1453840993 dot 18407 dot 2 dot camel at oc7878010663>
On 01/26/2016 09:43 PM, Steven Munroe wrote:
> On Tue, 2016-01-26 at 10:56 +0300, Yury Gribov wrote:
>> On 01/26/2016 03:24 AM, Joern Engel wrote:
>>> From: Joern Engel <joern@purestorage.org>
>>>
>>> It was disabled anyway and only served as obfuscation. No change
>>> post-compilation.
>>
>> FYI I've witnessed significant improvements from (real) __builtin_expect
>> in other projects.
>>
> It depends on the platform and if the programmer correctly understands
> the behavior of the program as written.
>
> Net, except for error cases that "should not happen, ever", a bad idea.
Based on what I saw, glibc uses __builtin_expect and the macros derived
from it in two conflicting ways: to express that one alternative is more
likely that the other, and to state that some alternative is impossible
in practice (for a well-behaved program in particular).
GCC's current interpretation leans towards the latter, at least on
x86_64. I think GCC even puts unlikely code into separate text sections
in some cases. Most of our __builtin_expect uses seem to be of the
former nature: things that can and do happen during normal operation,
like an unusual character in a character set conversion, or a
locale-related environment variable which is set.
I found it also problematic that GCC does the hot/cold partitioning (not
sure if it's actually called this way) on the error paths themselves,
where we already know that the impossible has happened, and all paths
eventually head towards an abort. It doesn't make sense for GCC to
split those that hit a known no-return function from those that hit a
function which does not return, but GCC cannot infer that from available
declarations.
Florian