[all-commits] [llvm/llvm-project] 532f4d: [AMDGPU] Make amdgpu.noclobber respect acquire ope...

[Fabian Ritter via All-commits]

  Branch: refs/heads/users/ritter-x2a/08-31-_amdgpu_make_amdgpu.noclobber_respect_acquire_operations
  Home:   https://github.com/llvm/llvm-project
  Commit: 532f4d81caab88ffc3871270b4dbeb4d70033137
      https://github.com/llvm/llvm-project/commit/532f4d81caab88ffc3871270b4dbeb4d70033137
  Author: Fabian Ritter <fabian.ritter at amd.com>
  Date:   2026-09-07 (Mon, 07 Sep 2026)

  Changed paths:
    M llvm/docs/AMDGPUMemoryModel.md
    M llvm/docs/AMDGPUUsage.rst
    M llvm/lib/Target/AMDGPU/AMDGPUAnnotateUniformValues.cpp
    M llvm/lib/Target/AMDGPU/AMDGPUMemoryUtils.cpp
    M llvm/test/CodeGen/AMDGPU/agpr-copy-no-free-registers.ll
    M llvm/test/CodeGen/AMDGPU/noclobber-barrier.ll

  Log Message:
  -----------
  [AMDGPU] Make amdgpu.noclobber respect acquire operations

AMDGPUAnnotateUniformValues should annotate uniform global loads as
`!amdgpu.noclobber` if the memory they are reading is never clobbered (since
kernel launch) before the load is executed. That allows the backend to use
scalar `s_load_*` instructions instead of vector loads (which would otherwise
be illegal because the scalar cache is not kept coherent with the vector
cache).

So far, loads were annotated if the thread executing the load has not clobbered
the relevant memory location, but changes from concurrent threads that were
acquired via synchronization were ignored (which is unsound).

This patch defines a semantics for `!amdgpu.noclobber` metadata in the
AMDGPUUsage and changes AMDGPUAnnotateUniformValues to respect that semantics.
Now, loads are no longer annotated if they are atomic or if an acquire fence or
load can be executed before them (since they can read from stores in other
threads in these cases).

The patch also fixes an unnecessarily pessimistic case, where atomic stores that
don't alias with the load were considered clobbering.

The noclobber definition uses `undef` instead of `poison` because data races are
currently still defined as `undef`; we need the noclobber definition to use the
same as the data race definition so that it's legal to infer noclobber if the
only way another thread could clobber the memory location would be a data race.

This implementation is overly pessimistic for one-as syncscopes: one-as acquire
operations that don't affect the global addrspace could be ignored for the
noclobber analysis. Improving this is left for a follow-up PR.

For ROCM-29879.


  Commit: b554bba26fab5a6ee5ce7816da6aa167e7f931e4
      https://github.com/llvm/llvm-project/commit/b554bba26fab5a6ee5ce7816da6aa167e7f931e4
  Author: Fabian Ritter <fabian.ritter at amd.com>
  Date:   2026-09-07 (Mon, 07 Sep 2026)

  Changed paths:
    M llvm/lib/Target/AMDGPU/AMDGPUMemoryUtils.cpp

  Log Message:
  -----------
  Rename "mayAlias" -> "MayAlias"


  Commit: dd3fe03d715b8638673f769d6a1d2606262368ce
      https://github.com/llvm/llvm-project/commit/dd3fe03d715b8638673f769d6a1d2606262368ce
  Author: Fabian Ritter <fabian.ritter at amd.com>
  Date:   2026-09-07 (Mon, 07 Sep 2026)

  Changed paths:
    M llvm/lib/Target/AMDGPU/AMDGPUAnnotateUniformValues.cpp
    M llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call.ll
    M llvm/test/CodeGen/AMDGPU/move-to-valu-addsubu64.ll
    M llvm/test/CodeGen/AMDGPU/move-to-valu-pseudo-scalar-trans-f16-fake16.ll
    M llvm/test/CodeGen/AMDGPU/move-to-valu-pseudo-scalar-trans-f16-true16.ll
    M llvm/test/CodeGen/AMDGPU/move-to-valu-pseudo-scalar-trans.ll
    M llvm/test/CodeGen/AMDGPU/noclobber-barrier.ll

  Log Message:
  -----------
  Don't infer noclobber for volatile accesses.


Compare: https://github.com/llvm/llvm-project/compare/77381f90f818...dd3fe03d715b

To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications