[Mlir-commits] [mlir] [mlir][spirv-to-llvm] Add conversion for spirv.MemoryBarrier (PR #232939)

[Arseniy Obolenskiy]

================
@@ -1385,6 +1385,62 @@ class ControlBarrierPattern : public SPIRVToLLVMConversion<BarrierOpTy> {
   }
 };
 
+/// Returns the LLVM atomic ordering denoted by the given SPIR-V memory
+/// semantics, or `std::nullopt` if the semantics set more than one ordering
+/// bit (which the SPIR-V dialect verifier rejects). Only the ordering bits
+/// (`Acquire`, `Release`, `AcquireRelease`, `SequentiallyConsistent`) are
+/// considered: the storage class bits (`UniformMemory`, `WorkgroupMemory`, ...)
+/// have no LLVM counterpart, and `MakeAvailable`/`MakeVisible` are implied by
+/// LLVM's release/acquire semantics. A semantics value with no ordering bit set
+/// is a relaxed atomic, i.e. `monotonic` in LLVM.
+static std::optional<LLVM::AtomicOrdering>
+convertMemorySemanticsToOrdering(spirv::MemorySemantics semantics) {
+  using spirv::MemorySemantics;
+  constexpr MemorySemantics orderingBits =
+      MemorySemantics::Acquire | MemorySemantics::Release |
+      MemorySemantics::AcquireRelease | MemorySemantics::SequentiallyConsistent;
+  switch (semantics & orderingBits) {
+  case MemorySemantics::None:
+    return LLVM::AtomicOrdering::monotonic;
+  case MemorySemantics::Acquire:
+    return LLVM::AtomicOrdering::acquire;
+  case MemorySemantics::Release:
+    return LLVM::AtomicOrdering::release;
+  case MemorySemantics::AcquireRelease:
+    return LLVM::AtomicOrdering::acq_rel;
+  case MemorySemantics::SequentiallyConsistent:
+    return LLVM::AtomicOrdering::seq_cst;
+  default:
+    return std::nullopt;
+  }
+}
+
+/// Converts `spirv.MemoryBarrier` to `llvm.fence`. A memory barrier without
+/// ordering semantics (relaxed) orders nothing and is erased: LLVM has no
+/// monotonic fence.
+class MemoryBarrierPattern
+    : public SPIRVToLLVMConversion<spirv::MemoryBarrierOp> {
+public:
+  using SPIRVToLLVMConversion<spirv::MemoryBarrierOp>::SPIRVToLLVMConversion;
+
+  LogicalResult
+  matchAndRewrite(spirv::MemoryBarrierOp op, OpAdaptor adaptor,
+                  ConversionPatternRewriter &rewriter) const override {
+    std::optional<LLVM::AtomicOrdering> ordering =
+        convertMemorySemanticsToOrdering(op.getMemorySemantics());
+    if (!ordering)
+      return rewriter.notifyMatchFailure(op, "unsupported memory semantics");
+    if (*ordering == LLVM::AtomicOrdering::monotonic) {
+      rewriter.eraseOp(op);
+      return success();
+    }
----------------
aobolensk wrote:

Is barrier drop a good solution? Can we consider more conservative fence option, since we don't have matching one?

Based on that we can (potentially) later come up with some heuristics to remove the barrier where it is justified

https://github.com/llvm/llvm-project/pull/232939