[llvm] [Doc][AMDGPU] Add barrier execution & memory model (PR #170447)

Nicolai Hähnle via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 4 10:26:36 PST 2025


================
@@ -6678,6 +6967,30 @@ following sections:
 * :ref:`amdgpu-amdhsa-memory-model-gfx12`
 * :ref:`amdgpu-amdhsa-memory-model-gfx125x`
 
+.. _amdgpu-amdhsa-execution-barriers-memory-model:
+
+Execution Barriers
+++++++++++++++++++
+
+.. note::
+  See :ref:`amdgpu-amdhsa-execution-barriers` for definitions of the terminology used
+  in this section.
+
+* A barrier *signal* operation ``S`` can pair with a release fence program-ordered before it
+  to form a ``barrier-signal-release`` ``BR``. The synchronization scope and the set of address
+  spaces affected are determined by the release fence.
+* A barrier *wait* operation ``W`` can pair with an acquire fence program-ordered after it to
+  form a ``barrier-wait-acquire`` ``BA``. The synchronization scope and the set of address
+  spaces affected are determined by the acquire fence.
+
+A ``BR`` *synchronizes-with* ``BA`` in an address space *AS* if and only if:
+
+* ``S`` *barrier-executes-before* ``W``.
+* *BA* and *BR*'s :ref:`synchronization scope<amdgpu-memory-scopes>` overlap.
+* *BA* and *BR*'s :ref:`synchronization scope<amdgpu-memory-scopes>`
+  allow cross address space synchronization (they cannot have ``one-as``).
----------------
nhaehnle wrote:

What is this last rule for?

(I've always felt that the `one-as` scopes are a bit weird and we should probably supersede them with something else, so this is more out of curiosity.)

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


More information about the llvm-commits mailing list