From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id A9E11384D154 for ; Thu, 20 Oct 2022 19:02:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A9E11384D154 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-ej1-x62c.google.com with SMTP id b2so1775735eja.6 for ; Thu, 20 Oct 2022 12:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=mUqRNdcvw/hm3krYPuTxG3fODfmAOUu2Kr8dQtWS86g=; b=c3YfYY6ajy3pC+KIOCbCGtigKdhS03rC7S5IzQ9jT48lWip3dmYxb2BTC/MohEwvOI DKvgqw2gG+CzbeJkXa+2BD5prdjW4H3MdxtxiHV5Ta+Wu4Hgx7brbarS+lRKYI1ljllU JsuwTKU/SeIa+apOybhGBkLlkKrEX2BgGg9vXh/Y97CiCDUovT44/U+mDYQXjXAWu7Zk pyL3C9/efkO07ltva2vHqs9/0p03HPhdrTwjJ99YAUVxOrQj2UFpZajGKeTxczdmZIVb jKCTbzNRoB232J5+K6E7meF11zXUCLPRBJh+FDp3AMtU3kBVX8AX58+0kx6k5RmjjUHW 2ZJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mUqRNdcvw/hm3krYPuTxG3fODfmAOUu2Kr8dQtWS86g=; b=afMBr5+h2OTBILvLeeOUeD3UUoCdHkPqaq9guD/+Wpo+0RTIjSbWovwFCr63dwQ8Lv hes6RJeeZG7vfyEPPLma/VbQZcntO3SccxP8OQ6toAvtWiVDRm2Spc2vnG21JQuiLvbP CbdGK2Ve9AO2gRP1Rv96c1ofG1fwZOuEJ+tas7PmAgEeVZf6AEBwe4HQLN0bxVnP8uQ3 dJdzc6gXQCuPiCY6GKlUGqih4FTgQ4WgUi5gETROaDWdZhwER6BjuQwtOwPtW/6UagoK woFiv7/PTYLHe5S5ex45rw6c4rKkkd386Bvwctma7i5P2/HGb60MVMsL7X/S0jrfJNHJ W8wA== X-Gm-Message-State: ACrzQf1CiVLgeM6E08YEUwFY783bgmb59SZ8SGWCRQ1NMHn4+DLg38Vs Max03FUhDSrEE9RQzHjgQQTt3w== X-Google-Smtp-Source: AMsMyM6YOtI8GGoEtIbwdPZCOMetKC/ZEjPxafT987gU3xi+fgKTlvPQ9RCFXabWEKC2H75DslJqAg== X-Received: by 2002:a17:907:d93:b0:78d:fe7a:f1fe with SMTP id go19-20020a1709070d9300b0078dfe7af1femr12638957ejc.721.1666292524268; Thu, 20 Oct 2022 12:02:04 -0700 (PDT) Received: from andrea (host-87-17-41-249.retail.telecomitalia.it. [87.17.41.249]) by smtp.gmail.com with ESMTPSA id l17-20020a1709063d3100b0073cf6ec3276sm10604478ejf.207.2022.10.20.12.02.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Oct 2022 12:02:03 -0700 (PDT) Date: Thu, 20 Oct 2022 21:01:58 +0200 From: Andrea Parri To: Palmer Dabbelt Cc: Vineet Gupta , jeffreyalaw@gmail.com, cmuellner@gcc.gnu.org, gcc-patches@gcc.gnu.org, kito.cheng@sifive.com, gnu-toolchain@rivosinc.com Subject: Re: [PATCH v2 00/10] [RISC-V] Atomics improvements [PR100265/PR100266] Message-ID: References: <3862a109-8083-7a36-3d85-8f9e5e10627c@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,KAM_SHORT,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Oct 12, 2022 at 07:16:20PM +0200, Andrea Parri wrote: > > > > +Andrea, in case he has time to look at the memory model / ABI > > > > issues. > > > +Jeff, who was offering to help when the threads got crossed. I'd punted on > > a lot of this in the hope Andrea could help out, as I'm not really a memory > > model guy and this is pretty far down the rabbit hole. Happy to have the > > help if you're offering, though, as what's there is likely a pretty big > > performance issue for anyone with a reasonable memory system. > > Thanks for linking me to the discussion and the remarks, Palmer. I'm > happy to help (and synchronized with Jeff/the community) as possible, > building a better understanding of the 'issues' at stake. Summarizing here some findings from looking at the currently-implemented and the proposed [1] mappings: - Current mapping is missing synchronization, notably atomic_compare_exchange_weak_explicit(-, -, -, memory_order_release, memory_order_relaxed); is unable to provide the (required) release ordering guarantees; for reference, I've reported a litmus test illustrating it at the bottom of this email, cf. c-cmpxchg. - [1] addressed the "memory_order_release" problem/bug mentioned above (as well as other quirks of the current mapping I won't detail here), but it doesn't address other problems present in the current mapping; in particular, both mappings translate the following atomic_compare_exchange_weak_explicit(-, -, -, memory_order_acquire, memory_order_relaxed); to a sequence lr.w bne sc.w.aq (withouth any other synchronization/fences), which contrasts with the the Unprivileged Spec, Section 10,2 "Load-Reserve / Store-Conditional Instructions": "Software should not set the 'rl' bit on an LR instruction unless the 'aq' bit is also set, nor should software set the 'aq' bit on an SC instruction unless the 'rl' bit is also set. LR.rl and SC.aq instructions are not guaranteed to provide any stronger ordering than those with both bits clear [...]" Thanks, Andrea [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595712.html C c-cmpxchg {} P0(atomic_int *x, atomic_int *y, int *z) { int r0; atomic_store_explicit(x, 1, memory_order_relaxed); r0 = atomic_compare_exchange_weak_explicit(y, z, 1, memory_order_release, memory_order_relaxed); } P1(atomic_int *x, atomic_int *y) { int r1; int r2; r1 = atomic_load_explicit(y, memory_order_acquire); r2 = atomic_load_explicit(x, memory_order_relaxed); } exists (1:r1=1 /\ 1:r2=0)