[llvm-branch-commits] [llvm] [AMDGPU] Make amdgpu.noclobber respect acquire operations (PR #219991)

[Fabian Ritter via llvm-branch-commits]

================
@@ -1290,9 +1284,9 @@ define amdgpu_kernel void @load_acquire_one_as_different(ptr addrspace(1) noalia
 define amdgpu_kernel void @fence_acquire_one_as_same(ptr addrspace(1) noalias %out, ptr addrspace(1) %p1, ptr addrspace(1) noalias %p1na) {
 ; CHECK-LABEL: define amdgpu_kernel void @fence_acquire_one_as_same(
 ; CHECK-SAME: ptr addrspace(1) noalias [[OUT:%.*]], ptr addrspace(1) [[P1:%.*]], ptr addrspace(1) noalias [[P1NA:%.*]]) {
-; CHECK-NEXT:    [[ACQ:%.*]] = load atomic i32, ptr addrspace(1) [[P1NA]] monotonic, align 4, !amdgpu.noclobber [[META0]]
+; CHECK-NEXT:    [[ACQ:%.*]] = load atomic i32, ptr addrspace(1) [[P1NA]] monotonic, align 4
 ; CHECK-NEXT:    fence syncscope("workgroup-one-as") acquire, !mmra [[META1:![0-9]+]]
----------------
ritter-x2a wrote:

Agreed with all of these points.

But this test case here doesn't involve any barriers. It's an atomic load from global with monotonic memory ordering, followed by an acquire fence with a `*-one-as` syncscope and an MMRA saying that the relevant "one AS" is the global one. If the load reads from a release store (or a monotonic store after a release fence) which affects at least the global address space, there is a happens-before relation (for accesses to the global address space, a little handwavy here since that part of the model is in active development) established between that release and this acquire fence.

As I understand it, the point with fences with `*-one-as` syncscope is that they can only pair (as the one in this test case here pairs with the prior global monotonic load) with operations in one specific addrspace. `s_barrier` operations operate in neither the global nor the local addrspace, therefore `*-one-as` fences cannot pair with them.

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