From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130181 invoked by alias); 4 Feb 2019 11:14:01 -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 130156 invoked by uid 89); 4 Feb 2019 11:14:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Therefore X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Feb 2019 11:13:59 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8F43480F6D; Mon, 4 Feb 2019 11:13:58 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-219.str.redhat.com [10.33.192.219]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 31C4E68D36; Mon, 4 Feb 2019 11:13:57 +0000 (UTC) From: Florian Weimer To: rth7680@gmail.com Cc: gcc-patches@gcc.gnu.org, ramana.radhakrishnan@arm.com, agraf@suse.de, matz@suse.de, Richard Henderson , libstdc++@gcc.gnu.org Subject: __libc_single_threaded variable for optimizing std::shared_ptr (was: [PATCH, AArch64 00/11] LSE atomics out-of-line) References: <20180926050355.32746-1-richard.henderson@linaro.org> Date: Mon, 04 Feb 2019 11:14:00 -0000 In-Reply-To: <20180926050355.32746-1-richard.henderson@linaro.org> (rth's message of "Tue, 25 Sep 2018 22:03:44 -0700") Message-ID: <871s4nu7po.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00169.txt.bz2 * Richard Henderson: > Therefore, I've created small out-of-line helpers that are directly > linked into every library or executable that requires them. There > will be two direct branches, both of which will be well-predicted. This work inspired me to put together something that provides a similar hidden variable, comparable to __aa64_have_atomics, to libc_nonshared.a in glibc: I hope it can be eventually be used to dynamically optimize the use of atomics in the std::shared_ptr implementation in libstdc++. For a generic optimization of all atomics, this is not suitable because even a single-threaded process can have MAP_SHARED mappings and will have to use atomics there. Thanks, Florian