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
