This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] malloc: remove __builtin_expect

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 <>
>>> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]