Re: [RFC] RISC-V: Add proposed Ztso atomic mappings

[Palmer Dabbelt <palmer@rivosinc.com>]

On Fri, 05 May 2023 11:55:31 PDT (-0700), Andrea Parri wrote:
> On Fri, May 05, 2023 at 10:12:56AM -0700, Patrick O'Neill wrote:
>> The RISC-V Ztso extension currently has no effect on generated code.
>> With the additional ordering constraints guarenteed by Ztso, we can emit
>> more optimized atomic mappings than the RVWMO mappings.
>>
>> This patch implements Andrea Parri's proposed Ztso mappings ("Proposed
>> Mapping").
>>   https://github.com/preames/public-notes/blob/master/riscv-tso-mappings.rst
>>
>> LLVM has implemented this same mapping (Ztso is still behind a
>> experimental flag in LLVM, so there is *not* a defined ABI for this yet).
>>   https://reviews.llvm.org/D143076
>
> Given the recent patches/discussions, it seems worth pointing out the
> the Ztso mappings referred to above was designed to be compatible with
> the mappings in Table A.6 and that they are _not_ compatible with the
> mappings in Table A.7 or with a "subset" of A.7 (even assuming RVTSO).

I guess that brings up the question of what we should do about WMO/TSO 
compatibility.  IIUC the general plan has been that WMO binaries would 
be compatible with TSO binaries when run on TSO systems, and that TSO 
binaries would require TSO systems.

I suppose it would be possible to have TSO produce binaries that would 
run on WMO systems by just emitting a bunch of extra fences, but I don't 
think anyone wants that?

We've always just assumed that WMO binaries would be compatible with TSO 
binaries, but I don't think it's ever really been concretely discussed.  
Having an ABI break here wouldn't be the craziest idea as it'd let us 
fix some other issues, but that'd certainly need to be pretty widely 
discussed.

Do we have an idea of what A.7-compatible TSO mappings would look like?