[PATCH] D143076: [RISCV] Implement a proposed mapping for Ztso

[Philip Reames via Phabricator via llvm-commits]

reames created this revision.
reames added reviewers: craig.topper, kito-cheng, asb, frasercrmck, lbenes, jrtc27.
Herald added subscribers: luke, VincentWu, vkmr, evandro, luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, shiva0217, niosHD, sabuasal, bollu, simoncook, johnrusso, rbar, hiraditya, arichardson, mcrosier.
Herald added a project: All.
reames requested review of this revision.
Herald added subscribers: pcwang-thead, eopXD, MaskRay.
Herald added a project: LLVM.

This change implements a proposed lowering from LLVM's memory model to the TSO memory model defined by the Ztso extension.  Selecting the proposed mapping turns out to be an involved conversation that really didn't fit within a review description, so let me refer you to https://github.com/preames/public-notes/blob/master/riscv-tso-mappings.rst.  This review implements the WMO compatible variant (the proposed one in that document).

Ztso is currently accepted as an experimental extension in LLVM.  Despite the fact the extension was recently ratified, I think we need to leave it as experimental until we have wide agreement on the chosen mapping for ABI purposes.

I need to note that the current in-tree implementation defaults to generating WMO compatible fences.  This is entirely compatible with the proposed mapping in this patch, but is unfortunately not compatible with the major alternative.  The in tree implementation is explicitly experimental so the impact of this is limited, but it is worth calling out that if settle on the alternative we will have a minor ABI break.  My apologies for not calling this out in the original patch; I had not realized at the time that one of our realistic choices for mappings wouldn't be WMO compatible.

This patch only contains the changes for load/store and fence.  That is, it does not change the lowering for atomicrmw operations.  This is a sound thing to do under the proposed mapping since the existing WMO mappings remain compatible.  I do plan to change these; I'm just working incrementally.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D143076

Files:
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/test/CodeGen/RISCV/atomic-fence.ll
  llvm/test/CodeGen/RISCV/atomic-load-store.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D143076.493945.patch
Type: text/x-patch
Size: 29370 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230201/eba3bfc8/attachment.bin>