From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) by sourceware.org (Postfix) with ESMTPS id D9BD2385B538 for ; Fri, 5 May 2023 21:42:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D9BD2385B538 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com Received: by mail-qt1-x82c.google.com with SMTP id d75a77b69052e-3ef36d814a5so1191221cf.0 for ; Fri, 05 May 2023 14:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683322969; x=1685914969; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BxMZxgRVwHR2/RUJ0NTzPpBt6RQ63f8i2e0k51dVr8Q=; b=PRW0kRURHO+F+i6XtNTlNC7crTGYIxmiUe7HaFpmOwQlee+j6EfjyYQDOZ6MszHA0r w2M68c9FJT+4qZbjqCqwqZwVMXbpkwTwHwd+jr8Giw3I8Ad05QMbSnuxHYqdGf6Uy32r Il4ZgjleV3ygvXG61ZKk2Yd6aHFsVFX7KM7EIJi1in31+xOGYL0FpySEAkJcFcl990DO ln1f8Pp3YLP+vB3fTmsJj/beZIzQ9IH6yCb1wUVAX01ocxNcQdTzliDaveceFwhQY5X+ ZLK2FBFkimKqCuZGShi7T+lxkw+Py0mFp9UgHWG71zNnL2TlxtF1RYsho8qxgqLastTE HscA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683322969; x=1685914969; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BxMZxgRVwHR2/RUJ0NTzPpBt6RQ63f8i2e0k51dVr8Q=; b=N34GiSynQ2peJgvL8RQoOP+JlkZM0OM3bNYjODlCEwGB1/NrGyqiGQTq5LW4RQZWOE VMikmtocIU3Ljg0/N5XSBR//cS/A4JqxFZJecCWqo7SIlH5DCFen7gEkq92NSknVTaJB 5F2gHkfJ1T8Se7yDKdCzSLmCcGwbP1+HwdNCgz3RmPMSg/KbNwKfgRPkpN9POC53oaWC ARenA8MG6foop1HiQ2o1F9Iuq/QNQeZql316MXkMxmUvpnMxBfI/RU8dWYs+7naTOo8v bWf11FdQSUsWoi+4aspQaypcy+CYUnjco5lnUMsaOGV3V71OIRoLXVa6KneXXStXXH1t 6KKQ== X-Gm-Message-State: AC+VfDxjaRNfUrNtukl9C0DtpUQu7YhNeX9aHDJSfe2M8nEqDAX1Tg9b IBmqAj0tuurpw69RC1yvjrkeaccwtM7WPGv+upyYag== X-Google-Smtp-Source: ACHHUZ7bFr6Gg1y95/VIw9PPDMItt0ZaF+/MQyw8npw4dGnvW18zAtX5yUMmjE3wgMWF4GKiHZfsC4NaAtXlp2CAmcU= X-Received: by 2002:a05:622a:1792:b0:3e0:c2dd:fd29 with SMTP id s18-20020a05622a179200b003e0c2ddfd29mr95336qtk.4.1683322969071; Fri, 05 May 2023 14:42:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hans Boehm Date: Fri, 5 May 2023 14:42:38 -0700 Message-ID: Subject: Re: [RFC] RISC-V: Add proposed Ztso atomic mappings To: Andrea Parri Cc: Palmer Dabbelt , "Patrick O'Neill" , gcc-patches@gcc.gnu.org, jeffreyalaw@gmail.com, Vineet Gupta , Andrew Waterman , kito.cheng@sifive.com, Daniel Lustig , cmuellner@gcc.gnu.org, gnu-toolchain@rivosinc.com Content-Type: multipart/alternative; boundary="0000000000009d98fc05faf92bda" X-Spam-Status: No, score=-17.2 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000009d98fc05faf92bda Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think A.6-tso also needs to change the last line in the table from lr.aqrl ... sc to lr.aq ... sc.rl, otherwise I think we have problems with a subsequent A.7-tso generated l.aq . Otherwise I agree. I certainly agree that, given the Ztso extension, there should be a standard compiler-implemented mapping that leverages it. I'm personally much less enthusiastic about calling it an ABI. I'd like to see clarity that the RVWMO ABI is the standard we expect portable libraries to be prepared to use. If they want to test for and use Ztso internally, fine. But having users deal with two different ABIs seems like a very high cost for avoiding some (basically no-op?) fences. Hans On Fri, May 5, 2023 at 1:11=E2=80=AFPM Andrea Parri w= rote: > On Fri, May 05, 2023 at 12:18:12PM -0700, Palmer Dabbelt wrote: > > On Fri, 05 May 2023 11:55:31 PDT (-0700), Andrea Parri wrote: > > > On Fri, May 05, 2023 at 10:12:56AM -0700, Patrick O'Neill wrote: > > > > The RISC-V Ztso extension currently has no effect on generated code. > > > > With the additional ordering constraints guarenteed by Ztso, we can > emit > > > > more optimized atomic mappings than the RVWMO mappings. > > > > > > > > This patch implements Andrea Parri's proposed Ztso mappings > ("Proposed > > > > Mapping"). > > > > > https://github.com/preames/public-notes/blob/master/riscv-tso-mappings.rst > > > > > > > > LLVM has implemented this same mapping (Ztso is still behind a > > > > experimental flag in LLVM, so there is *not* a defined ABI for this > yet). > > > > https://reviews.llvm.org/D143076 > > > > > > Given the recent patches/discussions, it seems worth pointing out the > > > the Ztso mappings referred to above was designed to be compatible with > > > the mappings in Table A.6 and that they are _not_ compatible with the > > > mappings in Table A.7 or with a "subset" of A.7 (even assuming RVTSO). > > > > I guess that brings up the question of what we should do about WMO/TSO > > compatibility. IIUC the general plan has been that WMO binaries would = be > > compatible with TSO binaries when run on TSO systems, and that TSO > binaries > > would require TSO systems. > > > > I suppose it would be possible to have TSO produce binaries that would > run > > on WMO systems by just emitting a bunch of extra fences, but I don't > think > > anyone wants that? > > > > We've always just assumed that WMO binaries would be compatible with TSO > > binaries, but I don't think it's ever really been concretely discussed. > > Having an ABI break here wouldn't be the craziest idea as it'd let us f= ix > > some other issues, but that'd certainly need to be pretty widely > discussed. > > > > Do we have an idea of what A.7-compatible TSO mappings would look like? > > As in riscv-tso-mappings.rst but with > > atomic_store(memory_order_seq_cst) | s{b|h|w|d} ; fence rw,rw > > would be A.7-compatible: call the resulting mappings "A.6-tso". > > A.6-tso is (also) compatible with the following subset of A.7: > > C/C++ Construct | A.7-tso Mapping > > -------------------------------------------------------------------------= ----- > Non-atomic load | l{b|h|w|d} > atomic_load(memory_order_relaxed | l{b|h|w|d} > atomic_load(memory_order_acquire) | l{b|h|w|d} > atomic_load(memory_order_seq_cst) | l{b|h|w|d}.aq > > -------------------------------------------------------------------------= ----- > Non-atomic store | s{b|h|w|d} > atomic_store(memory_order_relaxed) | s{b|h|w|d} > atomic_store(memory_order_release) | s{b|h|w|d} > atomic_store(memory_order_seq_cst) | s{b|h|w|d}.rl > > -------------------------------------------------------------------------= ----- > atomic_thread_fence(memory_order_acquire) | nop > atomic_thread_fence(memory_order_release) | nop > atomic_thread_fence(memory_order_acq_rel) | nop > atomic_thread_fence(memory_order_seq_cst) | fence rw,rw > > -------------------------------------------------------------------------= ----- > C/C++ Construct | RVTSO AMO Mapping > atomic_(memory_order_relaxed) | amo.{w|d} > atomic_(memory_order_acquire) | amo.{w|d} > atomic_(memory_order_release) | amo.{w|d} > atomic_(memory_order_acq_rel) | amo.{w|d} > atomic_(memory_order_seq_cst) | amo.{w|d} > > -------------------------------------------------------------------------= ----- > C/C++ Construct | RVTSO LR/SC Mapping > atomic_(memory_order_relaxed) | loop: lr.{w|d} ; ; > | sc.{w|d} ; bnez > loop > atomic_(memory_order_acquire) | loop: lr.{w|d} ; ; > | sc.{w|d} ; bnez > loop > atomic_(memory_order_release) | loop: lr.{w|d} ; ; > | sc.{w|d} ; bnez > loop > atomic_(memory_order_acq_rel) | loop: lr.{w|d} ; ; > | sc.{w|d} ; bnez > loop > atomic_(memory_order_seq_cst) | loop: lr.{w|d}.aq ; > ; > | sc.{w|d}.rl ; bnez > loop > > Andrea > --0000000000009d98fc05faf92bda--