From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id 22C4A3858D33 for ; Fri, 5 May 2023 20:11:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 22C4A3858D33 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-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-50bc0ced1d9so3363098a12.0 for ; Fri, 05 May 2023 13:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1683317466; x=1685909466; 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=/42LnMJzwvWfjthkGuTK1+H3IyeqMKmgG0tArCJ+FhM=; b=U5KPbebnPTlMlCEMsEblPV3Mi5A2464jnCGCsMiLoHS3v9Q9Sl89H0GtyZPebPh8KI sm8/N8roJUtkyM7/QEd0dTm6sFQRZQemK9cy5aL0Fi+MbTt5LkGmHXAqaYlwx7Ro5Ra8 OZae4cyEERSs3vN1bKIWBgcIsw4XK3DxgqJ821Ak/656zO2kp5i4SlD9JsoKU0m1w4sH kgRc/lN03R94CmF9ucNySPV81pmOzVGD5TSKxvHiso0Bp8QPvoiUOrmwwd2LExhEBtEF bPMNsl9lt7g3fesW/VYXFhyU0iVWD2YU92PYAY5hIzZ7h7L3+P79hOv7ueGTZxVcdGlZ aMig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683317466; x=1685909466; 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=/42LnMJzwvWfjthkGuTK1+H3IyeqMKmgG0tArCJ+FhM=; b=E7NQ/p9hgNRP7sHb4O1g6uSSAiM2Ba/kN5NRtT9mxDorbHdqHOvWNOA74vtOcDNkt5 ZiuTjTGUEWNybBmUOB14vR7vqzNcUsHTV5vsqVoyPs/ElPMeyaaXnQisrSGrruFQN8R7 2z+K2wWWANdnKcGRd6zGd447GkIrVMjtwJPcEPNlqxSLvsEP/fSrv/NscDv9Ty3kXsRI ang8fJC3vzqlNRTSYYD9qj/Uq3Wh5flzbLXubMyVSXHWcb3sE+GtJ7MsHNvXlQ1KTZgW wbeJPdSbQPd4oGLdr3CC+Ze2YGNrsTVRWcMRttyxWoFjNuJL2YBZse3SJGhRdYs05Rzz xJ9w== X-Gm-Message-State: AC+VfDxQL07k4JDxJ8HH1xgecUe1FO+oqtTnXTQnALlJK33LAzZ9VG58 bxYdfcdZAP2i/yflL/b66SDAPg== X-Google-Smtp-Source: ACHHUZ4TL0Wk42ovB2EUaDYnZaG9OJII9IUMTu5k0ItNTFAuALP+vDgjWBsMXCErxba6zzE8aabyxQ== X-Received: by 2002:aa7:c7d0:0:b0:50b:c62f:9ff0 with SMTP id o16-20020aa7c7d0000000b0050bc62f9ff0mr2237341eds.30.1683317465781; Fri, 05 May 2023 13:11:05 -0700 (PDT) Received: from andrea (host-87-1-71-229.retail.telecomitalia.it. [87.1.71.229]) by smtp.gmail.com with ESMTPSA id y25-20020aa7d519000000b0050b57848b01sm3190623edq.82.2023.05.05.13.11.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 May 2023 13:11:05 -0700 (PDT) Date: Fri, 5 May 2023 22:10:59 +0200 From: Andrea Parri To: Palmer Dabbelt Cc: 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, hboehm@google.com, gnu-toolchain@rivosinc.com Subject: Re: [RFC] RISC-V: Add proposed Ztso atomic mappings Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,KAM_ASCII_DIVIDERS,RCVD_IN_BARRACUDACENTRAL,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 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 fix > 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