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?
