[all-commits] [llvm/llvm-project] be6fe9: [RISCV] Implement a proposed mapping for Ztso

Philip Reames via All-commits all-commits at lists.llvm.org
Thu Feb 9 12:00:50 PST 2023


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: be6fe95673624f4faec4f7ed437842041b95b1e9
      https://github.com/llvm/llvm-project/commit/be6fe95673624f4faec4f7ed437842041b95b1e9
  Author: Philip Reames <preames at rivosinc.com>
  Date:   2023-02-09 (Thu, 09 Feb 2023)

  Changed paths:
    M llvm/docs/RISCVUsage.rst
    M llvm/lib/Target/RISCV/RISCVISelLowering.cpp
    M llvm/test/CodeGen/RISCV/atomic-fence.ll
    M llvm/test/CodeGen/RISCV/atomic-load-store.ll

  Log Message:
  -----------
  [RISCV] Implement a proposed mapping for Ztso

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.

Differential Revision: https://reviews.llvm.org/D143076




More information about the All-commits mailing list