From: Jeff Law <jeffreyalaw@gmail.com>
To: Andrea Parri <andrea@rivosinc.com>, Palmer Dabbelt <palmer@dabbelt.com>
Cc: Vineet Gupta <vineetg@rivosinc.com>,
cmuellner@gcc.gnu.org, gcc-patches@gcc.gnu.org,
kito.cheng@sifive.com, gnu-toolchain@rivosinc.com
Subject: Re: [PATCH v2 00/10] [RISC-V] Atomics improvements [PR100265/PR100266]
Date: Fri, 28 Oct 2022 23:02:22 -0600 [thread overview]
Message-ID: <bf379c2c-de2e-b50a-00d6-66912724a1f3@gmail.com> (raw)
In-Reply-To: <Y1GbJuhcBFpPGJQ0@andrea>
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
next prev parent reply other threads:[~2022-10-29 5:02 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-05 19:36 Christoph Muellner
2021-05-05 19:36 ` [PATCH v2 01/10] RISC-V: Simplify memory model code [PR 100265] Christoph Muellner
2021-05-05 19:36 ` [PATCH v2 02/10] RISC-V: Emit proper memory ordering suffixes for AMOs " Christoph Muellner
2021-05-05 19:36 ` [PATCH v2 03/10] RISC-V: Eliminate %F specifier from riscv_print_operand() " Christoph Muellner
2021-05-05 19:36 ` [PATCH v2 04/10] RISC-V: Use STORE instead of AMOSWAP for atomic stores " Christoph Muellner
2021-05-05 19:36 ` [PATCH v2 05/10] RISC-V: Emit fences according to chosen memory model " Christoph Muellner
2021-05-05 19:36 ` [PATCH v2 06/10] RISC-V: Implement atomic_{load,store} " Christoph Muellner
2021-05-05 19:36 ` [PATCH v2 07/10] RISC-V: Model INSNs for LR and SC [PR 100266] Christoph Muellner
2021-05-05 19:36 ` [PATCH v2 08/10] RISC-V: Add s.ext-consuming " Christoph Muellner
2021-05-05 19:36 ` [PATCH v2 09/10] RISC-V: Provide programmatic implementation of CAS " Christoph Muellner
2021-05-06 0:27 ` Jim Wilson
2021-05-05 19:36 ` [PATCH v2 10/10] RISC-V: Introduce predicate "riscv_sync_memory_operand" " Christoph Muellner
2022-10-11 19:06 ` [PATCH v2 00/10] [RISC-V] Atomics improvements [PR100265/PR100266] Vineet Gupta
2022-10-11 19:31 ` Palmer Dabbelt
2022-10-11 20:46 ` Christoph Müllner
2022-10-11 23:31 ` Vineet Gupta
2022-10-12 0:15 ` Palmer Dabbelt
2022-10-12 8:03 ` Christoph Müllner
2022-10-13 23:11 ` Jeff Law
2022-10-12 17:16 ` Andrea Parri
2022-10-20 19:01 ` Andrea Parri
2022-10-29 5:02 ` Jeff Law [this message]
2022-10-13 23:04 ` Jeff Law
2022-10-13 22:39 ` Jeff Law
2022-10-13 23:14 ` Palmer Dabbelt
2022-10-14 11:03 ` Christoph Müllner
2022-10-14 20:39 ` Jeff Law
2022-10-14 21:57 ` Palmer Dabbelt
2022-10-15 0:31 ` Palmer Dabbelt
2022-10-14 0:14 ` Vineet Gupta
2022-10-11 23:14 ` Jeff Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bf379c2c-de2e-b50a-00d6-66912724a1f3@gmail.com \
--to=jeffreyalaw@gmail.com \
--cc=andrea@rivosinc.com \
--cc=cmuellner@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=gnu-toolchain@rivosinc.com \
--cc=kito.cheng@sifive.com \
--cc=palmer@dabbelt.com \
--cc=vineetg@rivosinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).