From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110432 invoked by alias); 26 Jan 2016 21:08:01 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 110406 invoked by uid 89); 26 Jan 2016 21:07:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Net, H*f:sk:1453840, H*MI:sk:1453840, H*i:sk:1453840 X-HELO: mx1.redhat.com Subject: Re: [PATCH] malloc: remove __builtin_expect To: munroesj@linux.vnet.ibm.com, Yury Gribov References: <1453767942-19369-1-git-send-email-joern@purestorage.com> <1453767942-19369-21-git-send-email-joern@purestorage.com> <56A726C1.6070206@samsung.com> <1453840993.18407.2.camel@oc7878010663> Cc: Joern Engel , "GNU C. Library" , Siddhesh Poyarekar , Joern Engel From: Florian Weimer X-Enigmail-Draft-Status: N1110 Message-ID: <56A7E028.6050204@redhat.com> Date: Tue, 26 Jan 2016 21:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <1453840993.18407.2.camel@oc7878010663> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-01/txt/msg00764.txt.bz2 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 declarations. Florian