[llvm-branch-commits] [llvm] [LangRef][AMDGPU] Specify that syncscope can cause atomic operations to race (PR #189015)

via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Fri Mar 27 07:54:51 PDT 2026


llvmbot wrote:


<!--LLVM PR SUMMARY COMMENT-->

@llvm/pr-subscribers-llvm-ir

Author: Fabian Ritter (ritter-x2a)

<details>
<summary>Changes</summary>

Targets should be able to specify that the syncscope of atomic operations
influences whether they participate in data races with each other.

For example, in AMDGPU, we want (and already implement) the load in the
following case to be in a data race (i.e., return `undef` according to the
current definition), because there is an atomic store with workgroup syncscope
executing in a different workgroup:

```
; workgroup 0:
  store atomic i32 1, ptr %p syncscope("workgroup") monotonic, align 4

; workgroup 1:
  store atomic i32 2, ptr %p syncscope("workgroup") monotonic, align 4
  load atomic i32, ptr %p syncscope("workgroup") monotonic, align 4
```

This is consistent with the behavior of, e.g., [heterogeneous-race-free (HRF)
memory models](https://research.cs.wisc.edu/multifacet/papers/asplos14_hrf.pdf) and the [HSA memory model](https://hsafoundation.com/standards/).

---
Full diff: https://github.com/llvm/llvm-project/pull/189015.diff


2 Files Affected:

- (modified) llvm/docs/AMDGPUUsage.rst (+4-1) 
- (modified) llvm/docs/LangRef.rst (+2-1) 


``````````diff
diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst
index 1ede5ca2d4cf6..8ea0fa17518de 100644
--- a/llvm/docs/AMDGPUUsage.rst
+++ b/llvm/docs/AMDGPUUsage.rst
@@ -1144,7 +1144,10 @@ The memory model supported is based on the HSA memory model [HSA]_ which is
 based in turn on HRF-indirect with scope inclusion [HRF]_. The happens-before
 relation is transitive over the synchronizes-with relation independent of scope
 and synchronizes-with allows the memory scope instances to be inclusive (see
-table :ref:`amdgpu-amdhsa-llvm-sync-scopes-table`).
+table :ref:`amdgpu-amdhsa-llvm-sync-scopes-table`). Concurrent atomic operations
+only operate atomically with respect to each other if they are included in each
+other's sync scope. If a read R and the writes it may see are atomic but do not
+all have inclusive scopes, then R returns ``undef`` (see :ref:`memmodel`).
 
 This is different to the OpenCL [OpenCL]_ memory model which does not have scope
 inclusion and requires the memory scopes to exactly match. However, this
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 9e734caa3b497..bbe8ac4a44275 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -3933,7 +3933,8 @@ Given that definition, R\ :sub:`byte` is defined as follows:
 -  Otherwise, if R is atomic, and all the writes R\ :sub:`byte` may
    see are atomic, it chooses one of the values written. See the :ref:`Atomic
    Memory Ordering Constraints <ordering>` section for additional
-   constraints on how the choice is made.
+   constraints on how the choice is made. Targets may impose additional
+   requirements on R and the writes it may see based on their ``syncscope``.
 -  Otherwise R\ :sub:`byte` returns ``undef``.
 
 R returns the value composed of the series of bytes it read. This

``````````

</details>


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


More information about the llvm-branch-commits mailing list