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.
But I'm also sympathetic to the desire not to break existing code.
Could we keep the old behavior under a flag and fix the default behavior
here, presumably with a bit in the ELF header indicating code that wants
the old behavior?
Jeff
