From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id C091B3858C55; Thu, 13 Oct 2022 23:04:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C091B3858C55 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x1032.google.com with SMTP id q10-20020a17090a304a00b0020b1d5f6975so3238193pjl.0; Thu, 13 Oct 2022 16:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=A3I7pO6Z7jAjWpaW7BFlHQjMQDxaGi/D85yx76fwDTg=; b=YDByTwcdo29SKNrPk+OlDx7qTEXb+zr3pBCBY1+1rCt6GQZaWfLMsZ7CfH+0WIygBf GS5BD7v8Sp5BaMqO1xLgfOjpKE2ULuQBJROOXNP46lFP0Jewt7pIl38O+lKR+3aVWTiA oVvCQFWsLHFTOtAkFiMWIxjfHrWvWOUh3SX9tnvXSASMHOHQObfuZNu+Ni6EWbySqD22 W2h6HA1pH0Iogp772X6KQlz1w+G362fA5r82Wy+SqA0P5Jz8zvSKYovfhYUKgFmODUOo upM8moQv22EVigaARa9Id+px1SK/6YEK38zCauLYigQqXjit1/3SWtB0W9D6iHZXpUwg kJ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=A3I7pO6Z7jAjWpaW7BFlHQjMQDxaGi/D85yx76fwDTg=; b=fXd/XM/P3v3bLMJmRg04UH1XDYd25BLZGREEUo72smGiHADnyZvnabfWNv2qPNdvV/ nz9YV4S/BSobwWWxL2nIOEr43VvzJFeQSYld94UGDYiGi+fSAw43z5DziSuwjkNphBFN +MC/4X+55gs2eY4uDRqhBJeiJtv8sL4U/rOuATO24AiGrpWZJSe6Z8gvITZF8HlckDgh wX9QoSx2ao34NBxD0BEtDkfEe+zHbgbxULDvYxSHJw8KjYelfL506IrVkYoZWKkQkyfs OC/pPnTHjmMxh4xLkM8d9MnoZRunPKXPUoamlq6qmSqh6hOkgREh49gxZ8mDrR+471OI dCWw== X-Gm-Message-State: ACrzQf1bNKz2aOhQfotFKTQ3y2W6It0GZW/apdUiDpgqqqVw+DuTQeF+ F9HGn0vLgjEAmNML68gobEM= X-Google-Smtp-Source: AMsMyM56CSmO/dNLstw7VZGIkMXj3/zsdmlMJrmR36vHG6QIthxPxHgVmdtdbSbeG1Nqy61bVXsdQg== X-Received: by 2002:a17:902:e742:b0:17f:6a44:ee4a with SMTP id p2-20020a170902e74200b0017f6a44ee4amr2040173plf.103.1665702287623; Thu, 13 Oct 2022 16:04:47 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id 73-20020a63064c000000b0043c732e1536sm219726pgg.45.2022.10.13.16.04.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Oct 2022 16:04:47 -0700 (PDT) Message-ID: <249b7fd9-02f3-b7ad-2f8a-42302d5c454e@gmail.com> Date: Thu, 13 Oct 2022 17:04:45 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH v2 00/10] [RISC-V] Atomics improvements [PR100265/PR100266] Content-Language: en-US To: Palmer Dabbelt , Vineet Gupta Cc: cmuellner@gcc.gnu.org, Andrea Parri , gcc-patches@gcc.gnu.org, kito.cheng@sifive.com, gnu-toolchain@rivosinc.com References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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 10/11/22 18:15, Palmer Dabbelt wrote: > > Sorry, I thought we'd talked about it somewhere but it must have just > been in meetings and such.  Patrick was writing a similar patch set > around the same time so it probably just got tied up in that, we ended > up reducing it to just the strong CAS inline stuff because we couldn't > sort out the correctness of the rest of it. Now that you mention it, I vaguely recall a discussion about inline atomics vs libatomic and the discussion on this issue might have been there rather than in Christophe's patchset. > >>> My initial understanding was that fixing something broken cannot be >>> an ABI break. >>> And that the mismatch of the implementation in 2021 and the >>> recommended mappings in the ratified specification from 2019 is >>> something that is broken. I still don't know the background here, >>> but I guess this assumption is incorrect from a historical point of >>> view. > > We agreed that we wouldn't break binaries back when we submitted the > port.  The ISA has changed many times since then, including adding the > recommended mappings, but those binaries exist and we can't just > silently break things for users. That may be too strong of a policy -- just because something worked in the past doesn't mean it must always work.  It really depends on the contracts specified by the ABI, processor reference documentation, etc and whether or not the code relies on something that it outside those contracts.  If it does rely on behavior outside the contracts, then we shouldn't be constrained by such an agreement. Another way to think about this problem is do we want more code making incorrect assumptions about the behavior of atomics getting out in the wild?  My take would be that we nip this in the bud, get it right now in the default configuration, but leave enough bits in place that existing code continues to work. > >>> However, I'm sure that I am not the only one that assumes the >>> mappings in the specification to be implemented in compilers and >>> tools. Therefore I still consider the implementation of the RISC-V >>> atomics in GCC as broken (at least w.r.t. user expectation from >>> people that lack the historical background and just read the RISC-V >>> specification). > > You can't just read one of those RISC-V PDFs and assume that > implementations that match those words will function correctly. Those > words regularly change in ways where reasonable readers would end up > with incompatible implementations due to those differences.  That's > why we're so explicit about versions and such these days, we're just > getting burned by these old mappings because they're from back when we > though the RISC-V definition of compatibility was going to match the > more common one and we didn't build in fallbacks. Fair point, but in my mind that argues that the platform must mature further so that the contracts can be relied upon.  That obviously needs to get fixed and until it does any agreements or guarantees about behavior of existing code can't be reasonably made.  If we're going to be taken seriously, then those fundamentals have to be rock solid. > > I don't think we're just stuck with the status quo, we really just > need to go through the mappings and figure out which can be made both > fast and ABI-compatible.  Then we can fix those and see where we > stand, maybe it's good enough or maybe we need to introduce some sort > of compatibility break to make things faster (and/or compatible with > LLVM, where I suspect we're broken right now). Certainly seems like a good first step.  What we can fix without breaking things we do while we sort out the tougher problems. > > If we do need a break then I think it's probably possible to do it in > phases, where we have a middle-ground compatibility mode that works > for both the old and new mappings so distros can gradually move over > as they rebuild packages. As someone that lived in the distro space for a long time, I would argue that now is the time to fix this stuff -- before there is a large uptake in distro consumption. > > +Jeff, who was offering to help when the threads got crossed.  I'd > punted on a lot of this in the hope Andrea could help out, as I'm not > really a memory model guy and this is pretty far down the rabbit > hole.  Happy to have the help if you're offering, though, as what's > there is likely a pretty big performance issue for anyone with a > reasonable memory system. Hmm, there's a case I'm pondering if I can discuss  or not. Probably not since I can't recall it ever being discussed in public.  So I'll just say this space can be critically important for performance and the longer we wait, the tougher it gets to fix without causing significant disruption. Jeff