[Mlir-commits] [mlir] [MLIR][NVVM] Add summary and description fields for several OPs (PR #156726)
Durgadoss R
llvmlistbot at llvm.org
Thu Sep 4 11:58:27 PDT 2025
================
@@ -628,6 +827,52 @@ def NVVM_MBarrierTryWaitParitySharedOp : NVVM_PTXBuilder_Op<"mbarrier.try_wait.p
def NVVM_MBarrierTestWaitOp : NVVM_Op<"mbarrier.test.wait">,
Results<(outs LLVM_Type:$res)>,
Arguments<(ins LLVM_AnyPointer:$addr, LLVM_Type:$state)> {
+ let summary = "MBarrier Non-Blocking Test Wait Operation";
+ let description = [{
+ The `nvvm.mbarrier.test.wait` operation performs a non-blocking test for the
+ completion of a specific phase of an *mbarrier object*. It uses the default
+ `.acquire.cta` semantics. This acquire pattern establishes memory ordering for
+ operations occurring in program order after this wait instruction by making
+ operations from other threads visible to subsequent operations in the current
+ thread. When this wait completes, it synchronizes with the corresponding release
+ pattern from the `mbarrier.arrive` operation, establishing memory ordering within
+ the CTA.
+
+ This operation tests whether the mbarrier phase specified by the state operand
+ has completed. It is a non-blocking instruction that immediately returns the
+ completion status without suspending the executing thread.
+
+ The operation takes the following operands:
+ - `addr`: A pointer to the memory location of the *mbarrier object*. Uses generic
+ addressing, but the address must still be in the shared memory space.
+ - `state`: An opaque value returned by a previous `mbarrier.arrive`
+ operation on the same *mbarrier object* during the current or immediately
+ preceding phase.
+
+ The operation returns a boolean value indicating whether the specified phase
+ has completed:
+ - `true`: The immediately preceding phase has completed
+ - `false`: The phase is still incomplete (current phase)
+
+ **Memory ordering guarantees**: When this wait returns true, the following
+ ordering guarantees hold:
+
+ 1. All memory accesses (except async operations) requested prior to
+ `mbarrier.arrive` having release semantics by participating CTA threads
+ are visible to the executing thread.
+ 2. All `cp.async` operations requested prior to `cp.async.mbarrier.arrive`
+ by participating CTA threads are visible to the executing thread.
+ 3. All `cp.async.bulk` operations using the same *mbarrier object* requested
+ prior to `mbarrier.arrive` having release semantics by participating CTA
+ threads are visible to the executing thread.
+ 4. Memory accesses requested after this wait are not visible to memory
+ accesses performed prior to `mbarrier.arrive` by other participating
+ threads.
+ 5. No ordering guarantee exists for memory accesses by the same thread
+ between `mbarrier.arrive` and this wait.
----------------
durga4github wrote:
These 5 guarantees seem to be the same as the ones we have for try_wait. Can we just state that and not duplicate ?
https://github.com/llvm/llvm-project/pull/156726
More information about the Mlir-commits
mailing list