From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65485 invoked by alias); 26 Jul 2018 15:00:53 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 64869 invoked by uid 89); 26 Jul 2018 15:00:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=hurt, libsupc X-HELO: mail2-relais-roc.national.inria.fr Received: from mail2-relais-roc.national.inria.fr (HELO mail2-relais-roc.national.inria.fr) (192.134.164.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Jul 2018 15:00:20 +0000 Received: from stedding-dock.saclay.inria.fr ([193.55.177.248]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2018 17:00:07 +0200 Date: Thu, 26 Jul 2018 15:00:00 -0000 From: Marc Glisse Reply-To: gcc-patches@gcc.gnu.org To: =?ISO-8859-15?Q?Martin_Li=A8ka?= cc: gcc-patches@gcc.gnu.org, Jan Hubicka , Nathan Sidwell Subject: Re: [PATCH] Add malloc predictor (PR middle-end/83023). In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT X-SW-Source: 2018-07/txt/msg01663.txt.bz2 On Thu, 26 Jul 2018, Martin Liška wrote: > Following patch implements new predictors that annotates malloc-like functions. > These almost every time return a non-null value. Out of curiosity (the __builtin_expect there doesn't hurt and we don't need to remove it), does it make __builtin_expect unnecessary in the implementation of operator new (libstdc++-v3/libsupc++/new_op.cc)? It looks like while (__builtin_expect ((p = malloc (sz)) == 0, false)) { new_handler handler = std::get_new_handler (); if (! handler) _GLIBCXX_THROW_OR_ABORT(bad_alloc()); handler (); } where being in a loop may trigger opposite heuristics. -- Marc Glisse