[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:

Side note: I feel that we're going off topic for this PR here, maybe we should have the discussion about one-as fences elsewhere.

To the question: We don't generate any waits between the store and load in your example.
An `acq_rel` fence with `workgroup-one-as` syncscope and `amdgpu-synchronize-as:local` MMRA only needs to make sure that:
(1) the LDS stores before the fence do their writes before any atomic monotonic store **to LDS** after the fence and
(2) the LDS loads after the fence do their reads after any atomic monotonic load **from LDS** before the fence.

The HW automatically makes sure that a wave's LDS accesses (ds or flat to the LDS aperture) stay in order, so no waitcnt is necessary to implement that behavior.

If it wasn't a one-as fence, the above constraints would order the LDS stores before the fence with any atomic monotonic store (or barrier arrive) after the fence, not just those to LDS, and similarly order LDS loads after the fence with any atomic monotonic load (or barrier wait) before the fence, not just those from LDS. In that case, waiting would be necessary.

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