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

[via llvm-branch-commits]

================
@@ -3934,7 +3934,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``.
----------------
gonzalobg wrote:

@arsenm If we leave the specification of `syncscope` up to each target, afaict it would no longer be possible to optimize any atomic operation in the middle-end, cause atomic operations without `synscope` implicitly get `syncscope("")`, but the semantics of that would be "target-specific"... That is, I think for `syncscope` to be useful, the LangRef must precisely specify its semantics.

I think the spirit of `synscope` is to extend the definition of data-race as follows:

> The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, **at least one of which is not atomic at a scope that includes the thread that performed the other operation**, and neither happens before the other, except for the special case for signal handlers described below. Any such data race results in undefined behavior. […]

This justifies the `undef` for programs with data-races.
We also need to state that `syncscope("")` is the synchronization scope that includes all threads in the program, so that programs that don't explicitly generate `synscope` can fully ignore it.

---

A minimal change in the style of the current LangRef (i.e. not super precise or clean) may be:

> Otherwise, if R is atomic, and all the writes R\ :sub:`byte` may see are atomic, 
> **and the `synscope`s of R and of these writes include all threads that issued these operations**, 
> then R chooses one of the values written.

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