From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 936 invoked by alias); 2 Feb 2017 14:52:57 -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 907 invoked by uid 89); 2 Feb 2017 14:52:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=deacon, Deacon, msg00167html, H*MI:sk:a382eff 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; Thu, 02 Feb 2017 14:52:44 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CD0E2C05AA4A; Thu, 2 Feb 2017 14:52:44 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-117-185.ams2.redhat.com [10.36.117.185]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v12EqhEo010220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Feb 2017 09:52:44 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v12Eqewo004917; Thu, 2 Feb 2017 15:52:40 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v12Eqb88004916; Thu, 2 Feb 2017 15:52:37 +0100 Date: Thu, 02 Feb 2017 14:52:00 -0000 From: Jakub Jelinek To: Ramana Radhakrishnan Cc: Torvald Riegel , GCC Patches , Richard Henderson , Szabolcs Nagy , Will Deacon Subject: Re: [PATCH] Fix __atomic to not implement atomic loads with CAS. Message-ID: <20170202145237.GW14051@tucnak> Reply-To: Jakub Jelinek References: <1485802440.16721.118.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00170.txt.bz2 On Thu, Feb 02, 2017 at 02:48:42PM +0000, Ramana Radhakrishnan wrote: > On 30/01/17 18:54, Torvald Riegel wrote: > > This patch fixes the __atomic builtins to not implement supposedly > > lock-free atomic loads based on just a compare-and-swap operation. > > > > If there is no hardware-backed atomic load for a certain memory > > location, the current implementation can implement the load with a CAS > > while claiming that the access is lock-free. This is a bug in the cases > > of volatile atomic loads and atomic loads to read-only-mapped memory; it > > also creates a lot of contention in case of concurrent atomic loads, > > which results in at least counter-intuitive performance because most > > users probably understand "lock-free" to mean hardware-backed (and thus > > "fast") instead of just in the progress-criteria sense. > > > > This patch implements option 3b of the choices described here: > > https://gcc.gnu.org/ml/gcc/2017-01/msg00167.html > > > Will Deacon pointed me at this thread asking if something similar could be > done on ARM. > > On armv8-a we can implement an atomic load of 16 bytes using an LDXP / STXP > loop as a 16 byte load isnt' single copy atomic. On armv8.1-a we do have a > CAS on 16 bytes. If the AArch64 ISA guarantees LDXP is atomic, then yes, you can do that. The problem we have on x86_64 is that I think neither Intel nor AMD gave us guarantees that aligned SSE or AVX loads are guaranteed to be atomic. Jakub