From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by sourceware.org (Postfix) with ESMTPS id C4A9E3858C83; Fri, 14 Oct 2022 11:04:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C4A9E3858C83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gcc.gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qt1-f170.google.com with SMTP id hh9so3379774qtb.13; Fri, 14 Oct 2022 04:04:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=QaEjLaulw3pz1vy0QHTK8UtHK6vIkNE0v/Yj4i0ML/k=; b=33ie8GFwj2yCezEE2zT64iny7wqGWQrNO/Hk/fCFwO4IYylD3lTwF2sZnx4cQkryL6 eJAoWW2DxjFejaStWGXk3F3OBCPf6LEb1U+k1kMW2YTLlPNX4z82k2bmHm8hze1dW9YA HF84tnnCZ+RIp+FHFvUBpRR6QBXBoo/aplTYof1dze8yT1r73htAVo8la/ZPwgObZBXd 9WOjzL8+KSZEa1rgdgHFWgYdGgUgZUNvYyWfFn7uzMpg9m8Micyli+iPJwX8nMdJXzlu n6ZTYILvWJfrB8BETeBylIedyav9B1rQbamPu8em1zqkGvyP2iXtDA3ICWCkUgRMklj4 6NYQ== X-Gm-Message-State: ACrzQf0PNtiTQYbAxrJPPTe4qfAfW86quFtd1gpGUdr36VdGD93gelK9 ZAHCDlH2gJa5p861kMHGAYQy4QVuzJIgUq5v X-Google-Smtp-Source: AMsMyM4YfqFeyo3xmcBvjjA3VOSmpkoh9hwbNOhf4v2m4I3OzpyjqARUa7kUjQGCh/EcNiIHETNWOA== X-Received: by 2002:a05:622a:11c7:b0:39c:b4bc:7030 with SMTP id n7-20020a05622a11c700b0039cb4bc7030mr3572370qtk.17.1665745452047; Fri, 14 Oct 2022 04:04:12 -0700 (PDT) Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com. [209.85.219.175]) by smtp.gmail.com with ESMTPSA id g3-20020a05620a40c300b006eed14045f4sm320950qko.48.2022.10.14.04.04.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 04:04:11 -0700 (PDT) Received: by mail-yb1-f175.google.com with SMTP id j7so5158393ybb.8; Fri, 14 Oct 2022 04:04:11 -0700 (PDT) X-Received: by 2002:a25:c947:0:b0:6c2:63b4:83b3 with SMTP id z68-20020a25c947000000b006c263b483b3mr3814206ybf.428.1665745451348; Fri, 14 Oct 2022 04:04:11 -0700 (PDT) MIME-Version: 1.0 References: <47124771-dbfe-82c4-2f70-4b8c9fb19aa6@gmail.com> In-Reply-To: From: =?UTF-8?Q?Christoph_M=C3=BCllner?= Date: Fri, 14 Oct 2022 13:03:59 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 00/10] [RISC-V] Atomics improvements [PR100265/PR100266] To: Palmer Dabbelt Cc: gcc-patches@gcc.gnu.org, Vineet Gupta , Jeff Law , Christoph Muellner , Kito Cheng , gnu-toolchain@rivosinc.com, Philipp Tomsich , =?UTF-8?Q?Christoph_M=C3=BCllner?= Content-Type: multipart/alternative; boundary="000000000000e9fb9805eafc95bd" X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: --000000000000e9fb9805eafc95bd Content-Type: text/plain; charset="UTF-8" On Fri, Oct 14, 2022 at 1:15 AM Palmer Dabbelt wrote: > 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. > My guess is people like the ISA mapping (more) because it has been documented and reviewed. And it is the product of a working group that worked out the RVWMO specification. This gives some confidence that we don't need to rework it massively because of correctness issues in the future. The GCC mapping has (as far as I understand) never been documented and reviewed (especially not by the RISC-V arch review group). It might be faster and more robust, but it also might be incomplete and slower. Finding this out is a research topic with an unpredictable outcome. And more or less nobody wants to take this risk or has the time and the required skills to work on the research. > > 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. > I think a patch for legacy/isa can be done on time for the GCC release window. I can rework my series accordingly. However, I see some risk for the "both" option on the timeline, so this would have to wait until such a compatible mapping exists. > > 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... ;) > --000000000000e9fb9805eafc95bd--