[PATCH] malloc: remove __builtin_expect

[Steven Munroe]

On Tue, 2016-01-26 at 22:07 +0100, Florian Weimer wrote:
> 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 am also concerned the GCC has some serious bugs in its block frequency
handling. For example:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67755


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