[llvm] [AMDGPU] Improve the description of asyncmark semantics (PR #202579)

[Fabian Ritter via llvm-commits]

================
@@ -57,49 +55,54 @@ memory and LDS memory.
   void @llvm.amdgcn.tensor.load.to.lds(...)
   void @llvm.amdgcn.tensor.store.from.lds(...)
 
-Asyncmark Operations
----------------------
+Asyncmarks
+----------
 
 An *asyncmark* in the abstract machine tracks all the async operations that
-are *program-ordered* before that asyncmark. An asyncmark M is said to be *completed*
-only when all async operations *program-ordered* before M are reported by the
-implementation as having finished, and it is said to be *outstanding* otherwise.
-
-Thus we have the following sufficient condition:
-
-  An async operation X is *completed* at a program point P if there exists an
-  asyncmark M such that X is *program-ordered* before M, M is *program-ordered* before
-  P, and M is completed. X is said to be *outstanding* at P otherwise.
+are *program-ordered* before that asyncmark.
 
 The abstract machine maintains a sequence of asyncmarks during the
 execution of a function body, which excludes any asyncmarks produced by calls to
 other functions encountered in the currently executing function.
+This sequence is called the *current sequence* of that function body.
 
 ``@llvm.amdgcn.asyncmark()``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-When executed, inserts an asyncmark in the sequence associated with the
-currently executing function body.
+Appends an asyncmark to the current sequence.
 
 ``@llvm.amdgcn.wait.asyncmark(i16 %N)``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Waits until there are at most N outstanding asyncmarks in the sequence associated
-with the currently executing function body.
+Ensures that the length of the current sequence is at most ``N`` by removing
+asyncmarks from the start of the sequence if it is more than ``N``.
 
 Memory Consistency Model
 ========================
 
-Each asynchronous operation consists of a non-atomic read on the source and a
-non-atomic write on the destination. Async "LDS DMA" intrinsics result in async
-accesses that guarantee visibility relative to other memory operations as
-follows:
+An ``asyncmark()`` operation ``X`` that inserts an asyncmark ``M`` is
+*completed-at* a ``wait.asyncmark()`` operation ``Y`` in the same function body
+if:
+
+- ``X`` is *program-ordered* before ``Y``, and
+- ``M`` is not in the current sequence at any operation ``Z`` that immediately
+  follows ``Y`` in *program-order*.
+
+An async operation ``A`` is *completed-at* a ``wait.asyncmark()`` operation
+``Y`` if there exists an ``asyncmark()`` operation ``X`` such that:
+
+- ``A`` is *program-ordered* before ``X``, and
+- ``X`` is *completed-at* ``Y``.
 
-  An asynchronous operation `A` program ordered before an overlapping memory
-  operation `X` happens-before `X` only if `A` is completed before `X`.
+An asynchronous operation ``A`` *happens-before* an overlapping memory operation
----------------
ritter-x2a wrote:

Why only establish hb with overlapping memory operations (instead of, e.g., the `wait.asyncmark()` itself)? This means that I can't wait for an asynchronous operation to complete via `wait.asyncmark()` and then use a `store release` on some unrelated flag or a barrier synchronization with fences to ensure that other threads only do something after my async operation has completed.

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