From: Vineet Gupta <vineetg@rivosinc.com>
To: Jeff Law <jeffreyalaw@gmail.com>, gcc-patches@gcc.gnu.org
Cc: Palmer Dabbelt <palmer@rivosinc.com>,
Christoph Muellner <cmuellner@gcc.gnu.org>
Subject: Re: [PATCH v2 00/10] [RISC-V] Atomics improvements [PR100265/PR100266]
Date: Thu, 13 Oct 2022 17:14:32 -0700 [thread overview]
Message-ID: <975b8092-6bf2-f58d-147c-318e80c70b61@rivosinc.com> (raw)
In-Reply-To: <47124771-dbfe-82c4-2f70-4b8c9fb19aa6@gmail.com>
On 10/13/22 15:39, Jeff Law via Gcc-patches 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.
Exactly. I keep hearing about the potential ABI breakage but no real
discussion (publicly at least) which describe in detail what exactly
that ABI / old-behavior breakage is with this patch series [1]. So
perhaps we can start with reviewing the patches, calling out exactly
what change causes the divergence and if that is acceptable or not. And
while at it, perhaps also make updates to [2]
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595712.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100265
next prev parent reply other threads:[~2022-10-14 0:14 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
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 [this message]
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=975b8092-6bf2-f58d-147c-318e80c70b61@rivosinc.com \
--to=vineetg@rivosinc.com \
--cc=cmuellner@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jeffreyalaw@gmail.com \
--cc=palmer@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).