From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id 891133858C56 for ; Thu, 13 Oct 2022 23:14:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 891133858C56 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pg1-x52a.google.com with SMTP id h185so2814981pgc.10 for ; Thu, 13 Oct 2022 16:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=YLM/EErDgRSdt/hPBx6cXDK9Fvwc5pa80m8UKS91ZH8=; b=Q1zvxyyyfxFyCsltzWmfjlkcrvER45//AOGfB+nhuVpuwlsjLdv+loJMp72seZDdRT 6AHZLR+ek5PVMJcgYPSV2O5FoZQWiYTQjBak2deZayN+y0g/93xpfrSbrKaHOI9xzr/w zmma+r4nQn/JZGKIg9XoQRdvrP2Fouaz8kBwTNXAI02rs2jUo5ET1x2xm/1PlLvPP0RB whCx8YM05tZ5hjyIxgksyTAGtFKahBjo2yiBmzBRAwJfbrhB7/VbKwjQQVCO74Cqj1Cy y8GnBNFRcZHHnDkcfGQZ9F6DWV24vqD/YTbeeXDdQlDA0dcHiJwW+tuZHL7mVSGDtx7l xeRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YLM/EErDgRSdt/hPBx6cXDK9Fvwc5pa80m8UKS91ZH8=; b=Wfp0KdqXS3og8kS0InB0Z11Gk5io3pAEdvcJeVf2mU2YcKNu+CLqvXBKpP8e6TPGIn xufn8LADxFy0r3IWzVijseFa69KDyrlGWc1SvRNwNWOhjhrpkD3mjd1qfxoRB2Hl8Ac3 gVu/OByVARDQYUXLcPu8jseKGp+YPW5SvIqypLUJ1+j+YWWFM8AfPelT/Zf1xtXzo4xT Y45XDD0JuHxsTuJ1NJgOmziKKIIwCDFVSLR+VoL4E220iw950/+VUkcW3w/JqMGwnylF TLiGcJatXPwRBi+L03rDkcKgf7/AXdJ7krQveePYL4marqgkSpr3AHzJFkd23ZtgmKsS Fqpw== X-Gm-Message-State: ACrzQf2p5tiFU3pCECYlRedjW/bYGamLG5wzoW1RdPBW2YrwT/2f+tb/ p4ombIERI1HbR8Ob8wuAOuhhP0o/BkBnmg== X-Google-Smtp-Source: AMsMyM51ucmN+QdqqpNMep7d9zJcaskpANMFtIcc8FpMwhzIiNge1KWcwYlL0Od8T9fQpdyoNPmU8g== X-Received: by 2002:a63:6b44:0:b0:46a:fa55:b6a0 with SMTP id g65-20020a636b44000000b0046afa55b6a0mr1968613pgc.614.1665702881748; Thu, 13 Oct 2022 16:14:41 -0700 (PDT) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id a188-20020a624dc5000000b005629d8a3204sm235705pfb.99.2022.10.13.16.14.40 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Oct 2022 16:14:41 -0700 (PDT) Date: Thu, 13 Oct 2022 16:14:41 -0700 (PDT) X-Google-Original-Date: Thu, 13 Oct 2022 16:14:43 PDT (-0700) Subject: Re: [PATCH v2 00/10] [RISC-V] Atomics improvements [PR100265/PR100266] In-Reply-To: <47124771-dbfe-82c4-2f70-4b8c9fb19aa6@gmail.com> From: Palmer Dabbelt To: gcc-patches@gcc.gnu.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: On Thu, 13 Oct 2022 15:39:39 PDT (-0700), gcc-patches@gcc.gnu.org wrote: > > On 10/11/22 17:31, Vineet Gupta wrote: >> >>> >>> I expect that the pressure for a proper fix upstream (instead of a >>> backward compatible compromise) will increase over time (once people >>> start building big iron based on RISC-V and start hunting performance >>> bottlenecks in multithreaded workloads to be competitive). >>> What could be done to get some relief is to enable the new atomics >>> ABI by a command line switch and promote its use. And at one point in >>> the future (if there are enough fixes to justify a break) the new ABI >>> can be enabled by default with a new flag to enable the old ABI. >> >> Indeed we are stuck with inefficiencies with status quo. The new abi >> option sounds like a reasonable plan going fwd. >> >> Also my understand is that while the considerations are ABI centric, >> the option to faciliate this need not be tied to canonical -mabi=lp32, >> lp64d etc. It might just be a toggle as -matomic=legacy,2019 etc (this >> is not suggestive just indicative). Otherwise there's another level of >> blowup in multilib testing etc. > > If I understand the history here, we're essentially catering to code > that is potentially relying on behavior that was never really > guaranteed.   That's not really ABI -- it's more depending on specifics > of an implementation or undefined/underdefined behavior.    Holding back > progress for that case seems short-sighted, particularly given how early > I hope we are in the RISC-V journey. > > > But I'm also sympathetic to the desire not to break existing code.  I suppose ABI means a ton of things, but in this case that's really want I was trying to get at: just changing to the mappings suggested in the ISA manual risks producing binaries that don't work when mixed with old binaries. My rationale for calling that ABI was that there's a defacto memory model ABI defined as "anything that works with the old binaries", but ABI means so many things maybe we just shouldn't say it at all here? I'm going to call it "old binary compatibility" here, rather than "ABI compatibility", just so it's a different term. > Could we keep the old behavior under a flag and fix the default behavior > here, presumably with a bit in the ELF header indicating code that wants > the old behavior? The thread got forked a bit, but that's essentially what I was trying to suggest. I talked with Andrea a bit and here's how I'd describe it: We have a mapping from the C{,++}11 memory model to RVWMO that's currently emitted by GCC, and there are years of binaries with that mapping. As far as we know that mapping is correct, but I don't think anyone's gone through and formally analyzed it. Let's call those the "GCC mapping". There's also a mapping listed in the ISA manual. That's not the same as the GCC mapping, so let's call it the "ISA mapping". We need to double-check the specifics, but IIUC this ISA mapping is broadly followed by LLVM. It's also very likely to be correct, as it's been analyzed by lots of formal memory model people as part of the RVWMO standardization process. As far as I know, everyone likes the ISA mapping better than the GCC mapping. It's hard to describe why concretely because there's no hardware that implements RVWMO sufficiently aggressively that we can talk performance, but at least matching what's in the ISA manual is the way to go. Also, just kind of a personal opinion, the GCC mapping does some weird ugly stuff. So the question is really: how do we get rid of the GCC mapping while causing as little headache as possible? My proposal is as follows: * Let's properly analyze the GCC mapping, just on its own. Maybe it's broken, if it is then I think we've got a pretty decent argument to just ignore old binary compatibility -- if it was always broken then we can't break it, so who cares. * Assuming the GCC mapping is internally consistent, let's analyze arbitrary mixes of the GCC and ISA mappings. It's not generally true that two correct mappings can be freely mixed, but maybe we've got some cases that work fine. Maybe we even get lucky and everything's compatible, who knows (though I'm worried about the same .aq vs fence stuff we've had in LKMM a few times). * Assuming there's any issue mixing the GCC and ISA mappings, let's add a flag to GCC. Something like -mrvwmo-compat={legacy,both,isa}, where: - =legacy does what we have now. We can eventually deprecate this, and assuming =both is fast enough maybe we don't even need it. - =both implements a mapping that's compatible with both the GCC and ISA mappings. This might be slow or something, but it'll be correct with both. We can set this to the default now, as it's safe. - =isa implements the ISA mappings. Then we can go stick some marker in the ELF saying "this binary is compatible with the ISA mappings" to triage binaries in systems. That way distros can decide when they want to move to -mrvwmo-compat=isa by default, maybe when they naturally do a world rebuild. Eventually we can make that the default in GCC upstream and later deprecate the compatibility modes. That's going to take a bit of work on the formal memory model side of things, but I think we've at least got enough of Andrea's bandwidth to make it happen in a reasonable timeframe. I don't think there's a ton of implementation work to do once we sort out the desired mappings, and a chunk of that can probably start in parallel as we'll likely need stuff like the ELF tagging eventually. Landing this before stage4 might be tricky, though. I tell myself we're not going to take late backend features every release... ;)