From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by sourceware.org (Postfix) with ESMTPS id 668B63858D35; Sat, 29 Oct 2022 05:02:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 668B63858D35 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-x102c.google.com with SMTP id h14so6270537pjv.4; Fri, 28 Oct 2022 22:02:25 -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=2dv/XZSHx83r9kXUN5yEApoQcjwCrC+mMlJdGCT92n0=; b=N8YXFM3YNwpL5dEPHmihGKH6I2S6H/1X3pb29EZSKH7tvDFZakPCovx2rkm3/j17FE C83IZvC+Ss+73SXFTmnckZ3bYhof1X6VwoBCcGrHX44UuARsqCJeYzbS6hUCLmR4saGB z+PskTnAIiC3Kud51q94i6s+UFgwOVPhsyM8Ng+q20wd/3pE8ZGD/mnvf6r0GRruQU8I vrKCG52Loej9KLwbomoRnsg4zG6+iCR1hJRmZa9QQ2E1rVYmMBw2YPWZB0qAxtoCqVnB 1Ko3U4zfVoPipCAfWDmtgF9pWF2zZGbc/Ud5Blc3/chvqZB8NedlkV8t+SKyOUbBLEGp J+TQ== 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=2dv/XZSHx83r9kXUN5yEApoQcjwCrC+mMlJdGCT92n0=; b=hnTdcvuBaZw6z+zaxcf2HA4c917gBI8Tdy0s/1FPjiAmtBqCnL8XJMbwCrXHmsey8f 8ZidUpcg1lQEDPAXD/g8sheZrftj087ycBax5T9gVrRJnKtAZmpX+OXbv4IiS8OO0BaQ Pwmw/U86DSyVxAiamuWiplAo0ndW36SBnFLsH8RuYGc8iRftt0XYf6LNquSMYfFaz3m5 wNkbsrMvfrGFMWzqOyKLVG2wciZLAYUyRr3jLhou7BVqfrpUzBk/GG2Y1ZmJqUNn3XNc ryugE+7G8s3aFCmrbLBqrQWioB09QS3CfdulcGwcWb8UHgXcY1Wnn/ph877mK03KDR88 lpAg== X-Gm-Message-State: ACrzQf3GN5sgCEGgI2MwvI1TmIsLQOkMOHqFeyNmBDRNZyb5PhgFZVeU WWOjsAwuahyDmnT5BwliK70= X-Google-Smtp-Source: AMsMyM7xonE+mp8MlYunWCYRMq1RlxxK3xqpzL/JsbFCIqE7wPU6gn8JiMCLLC0D41jbJcEkNGCXmg== X-Received: by 2002:a17:90a:4588:b0:205:d605:8bcc with SMTP id v8-20020a17090a458800b00205d6058bccmr2972072pjg.205.1667019744307; Fri, 28 Oct 2022 22:02:24 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id u10-20020a170902714a00b001730a1af0fbsm346917plm.23.2022.10.28.22.02.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 22:02:23 -0700 (PDT) Message-ID: Date: Fri, 28 Oct 2022 23:02:22 -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: Andrea Parri , Palmer Dabbelt Cc: Vineet Gupta , cmuellner@gcc.gnu.org, gcc-patches@gcc.gnu.org, kito.cheng@sifive.com, gnu-toolchain@rivosinc.com References: <3862a109-8083-7a36-3d85-8f9e5e10627c@rivosinc.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 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/20/22 13:01, Andrea Parri wrote: > On Wed, Oct 12, 2022 at 07:16:20PM +0200, Andrea Parri wrote: >>>>> +Andrea, in case he has time to look at the memory model / ABI >>>>> issues. >>> +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. >> Thanks for linking me to the discussion and the remarks, Palmer. I'm >> happy to help (and synchronized with Jeff/the community) as possible, >> building a better understanding of the 'issues' at stake. > Summarizing here some findings from looking at the currently-implemented > and the proposed [1] mappings: > > - Current mapping is missing synchronization, notably > > atomic_compare_exchange_weak_explicit(-, -, -, > memory_order_release, > memory_order_relaxed); > > is unable to provide the (required) release ordering guarantees; for > reference, I've reported a litmus test illustrating it at the bottom > of this email, cf. c-cmpxchg. > > - [1] addressed the "memory_order_release" problem/bug mentioned above > (as well as other quirks of the current mapping I won't detail here), > but it doesn't address other problems present in the current mapping; > in particular, both mappings translate the following > > atomic_compare_exchange_weak_explicit(-, -, -, > memory_order_acquire, > memory_order_relaxed); > > to a sequence > > lr.w > bne > sc.w.aq > > (withouth any other synchronization/fences), which contrasts with the > the Unprivileged Spec, Section 10,2 "Load-Reserve / Store-Conditional > Instructions": > > "Software should not set the 'rl' bit on an LR instruction unless > the 'aq' bit is also set, nor should software set the 'aq' bit on > an SC instruction unless the 'rl' bit is also set. LR.rl and SC.aq > instructions are not guaranteed to provide any stronger ordering > than those with both bits clear [...]" So it sounds like Christoph's patch is an improvement, but isn't complete.  Given the pain in this space, I'd be hesitant to put in an incomplete fix, even if it moves things in the right direction as it creates another compatibility headache if we don't get the complete solution in place for gcc-13. Christoph, thoughts on the case Andrea pointed out? Jeff