[all-commits] [llvm/llvm-project] 450387: [IR][FunctionAttrs] Clarify memory effects of atom...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4503872fe57315e6df7dbc93128dbe6a02011872
      https://github.com/llvm/llvm-project/commit/4503872fe57315e6df7dbc93128dbe6a02011872
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2026-05-28 (Thu, 28 May 2026)

  Changed paths:
    M clang/test/CodeGenOpenCL/atomic-builtins-default-to-device-scope.cl
    M llvm/include/llvm/IR/Instruction.h
    M llvm/lib/IR/Instruction.cpp
    M llvm/lib/Transforms/IPO/FunctionAttrs.cpp
    M llvm/test/Transforms/FunctionAttrs/atomic.ll
    M llvm/test/Transforms/FunctionAttrs/nocapture.ll
    M llvm/test/Transforms/FunctionAttrs/nosync.ll
    M llvm/test/Transforms/FunctionAttrs/writeonly.ll

  Log Message:
  -----------
  [IR][FunctionAttrs] Clarify memory effects of atomics (#193768)

FunctionAttrs was treating atomic instructions, including with ordering
stronger than monotonic, as only reading/writing their operand.

I don't think doing this is correct, because we model the ordering
constraints of synchronizing atomics via reading/writing "all" memory.
So e.g. if you have a function with a release store on an argument,
marking it as argmem-only is wrong, because that would permit reordering
accesses to other locations around it. (What this PR is doing is not
*sufficient* to model this correctly due to the fence-like effects on
not-yet-escaped memory, but it brings us closer to correctness.)

I initially tried to implement mayReadFromMemory() and
mayWriteToMemory() on top of getMemoryEffects(), but this caused
significant compile-time regressions, so I've kept the logic duplicated.



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