From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 151A73858D35 for ; Fri, 5 May 2023 21:52:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 151A73858D35 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-il1-x133.google.com with SMTP id e9e14a558f8ab-331333e6bf1so5787475ab.3 for ; Fri, 05 May 2023 14:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1683323559; x=1685915559; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wKjvmBNbqSvT4sNe8rUPWBqbmeXAEaz89f676cVzeiE=; b=R4aMnkJ2i55e4LW7m9OhfU/obfUb0qvrr1R/CUmXZmDYz3SnCYAlr9m4kYFpUyiGyH BJoMmEOyMCckWfUzQhoMBUzhVz4w9b7+yuo1M5XlNe+2djAmdpSy6MGZ7hZ+OOANbO0r ACrmO5qHaR8rpoJSKCfOMCg8Xo4mWdsvalx23O7BC9Mk/puyQWUA78KzT10Ellh+W+gz TspITjsbgGDVcX9mq5ZQOBOxNAc4hNpV7CbSbNJmtmKyE3PGg16hqDgHaJiV7MQBTSZW Q5YhKhZ2t9aetZptYf/hDiDaA0tamHihEr+WFCAXBN7ZVJTtcjhQc6zjhZwmYoq2a2WW ZI3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683323559; x=1685915559; h=content-transfer-encoding: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=wKjvmBNbqSvT4sNe8rUPWBqbmeXAEaz89f676cVzeiE=; b=d/q8YCPMfxI6jX1Pttm0FnpfOMQidj0GwgYdOvwi/Avb+31VPhIzhDhXEt/qK6xdVd zBMPt5c0SMHhVlW5BR/+U8tJ5tbr3dj2U6U9HuFismgZC9p/OFA+fnDOJIyo0dBiEzrJ 9xf+BheZIiKVi1WdNwS1Qbh6jJMd8hWrwadzozvB/VaRXeyg0vcVMOmLt4CuvnPdTMJz w9812jKdTvlBrE8zPJCrC5NhLGiRWw/Gff+CbZd0xqG1UAi7MiA/bGytxr5BqZ3nuuMK jigW8cGGJO0TUc6Gf1Lbw8C2pQ4VIjWdl2602freopqgPQUTJHGKWvlg3RiKVsd7MS9Y evCQ== X-Gm-Message-State: AC+VfDx3grkST76q6sp8ngd5Nbi3Uf6FyXJWi3ocArOJl4k2nEgLrIHC 2Ob0O37U2idryrrGi8MRfCNZ0mRROb6xZRj49yRQVh5WaZKrXDY15LQhrGZjlX8jdT0DBclZVz1 Kx09n1ijo7TfMYiZWxe1I/jrhEWfpzH80NB3MzHnRdWvp2FTngIWejoTTR2cM6OndyndArBL0rw == X-Google-Smtp-Source: ACHHUZ4ahi6C6pRefWbf1ncWNs2hyBfLPrZjkM1Bl5BRV0nIYYK4whNI95mWsdYVNJSV3pmrw5nNfQ== X-Received: by 2002:a05:6e02:4cd:b0:32c:dc61:8e84 with SMTP id f13-20020a056e0204cd00b0032cdc618e84mr1609993ils.4.1683323559099; Fri, 05 May 2023 14:52:39 -0700 (PDT) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com. [209.85.166.45]) by smtp.gmail.com with ESMTPSA id a14-20020a92d34e000000b0032732e7c25esm715123ilh.36.2023.05.05.14.52.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 May 2023 14:52:38 -0700 (PDT) Received: by mail-io1-f45.google.com with SMTP id ca18e2360f4ac-760f8ffb27fso53833139f.2; Fri, 05 May 2023 14:52:37 -0700 (PDT) X-Received: by 2002:a5e:8816:0:b0:764:fef5:12d9 with SMTP id l22-20020a5e8816000000b00764fef512d9mr1606086ioj.11.1683323557017; Fri, 05 May 2023 14:52:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Waterman Date: Fri, 5 May 2023 14:52:25 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] RISC-V: Add proposed Ztso atomic mappings To: Hans Boehm Cc: Andrea Parri , Palmer Dabbelt , "Patrick O'Neill" , gcc-patches@gcc.gnu.org, jeffreyalaw@gmail.com, Vineet Gupta , kito.cheng@sifive.com, Daniel Lustig , cmuellner@gcc.gnu.org, gnu-toolchain@rivosinc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Fri, May 5, 2023 at 2:42=E2=80=AFPM Hans Boehm wrote= : > > I think A.6-tso also needs to change the last line in the table from lr.a= qrl ... sc to lr.aq ... sc.rl, otherwise I think we have problems with a su= bsequent A.7-tso generated l.aq . Otherwise I agree. > > I certainly agree that, given the Ztso extension, there should be a stand= ard compiler-implemented mapping that leverages it. I'm personally much les= s enthusiastic about calling it an ABI. I'd like to see clarity that the RV= WMO ABI is the standard we expect portable libraries to be prepared to use. There's already a ratified sentiment that effectively implies this. Ztso is not required by the RVA profiles, and so it follows that any binary that's compatible across RVA-profile implementations cannot assume the presence of Ztso. (I agree the ABI should encode this property for de jure purposes, too, but it's already a de facto requirement.) > 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 = wrote: >> >> 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 cod= e. >> > > > With the additional ordering constraints guarenteed by Ztso, we ca= n emit >> > > > more optimized atomic mappings than the RVWMO mappings. >> > > > >> > > > This patch implements Andrea Parri's proposed Ztso mappings ("Prop= osed >> > > > Mapping"). >> > > > https://github.com/preames/public-notes/blob/master/riscv-tso-ma= ppings.rst >> > > > >> > > > LLVM has implemented this same mapping (Ztso is still behind a >> > > > experimental flag in LLVM, so there is *not* a defined ABI for thi= s yet). >> > > > https://reviews.llvm.org/D143076 >> > > >> > > Given the recent patches/discussions, it seems worth pointing out th= e >> > > the Ztso mappings referred to above was designed to be compatible wi= th >> > > the mappings in Table A.6 and that they are _not_ compatible with th= e >> > > 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 bin= aries >> > 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 t= hink >> > anyone wants that? >> > >> > We've always just assumed that WMO binaries would be compatible with T= SO >> > 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 = fix >> > some other issues, but that'd certainly need to be pretty widely discu= ssed. >> > >> > 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 ; bn= ez loop >> >> Andrea