[all-commits] [llvm/llvm-project] 78c586: [LoopFusion] Reject loops containing atomic access...

[Madhur Amilkanthwar via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 78c586615f1b31c6c5f3d37a6638c76cdb821388
      https://github.com/llvm/llvm-project/commit/78c586615f1b31c6c5f3d37a6638c76cdb821388
  Author: Madhur Amilkanthwar <madhura at nvidia.com>
  Date:   2026-06-05 (Fri, 05 Jun 2026)

  Changed paths:
    M llvm/lib/Transforms/Scalar/LoopFuse.cpp
    A llvm/test/Transforms/LoopFusion/cannot_fuse_atomic.ll

  Log Message:
  -----------
  [LoopFusion] Reject loops containing atomic accesses (#201525)

The fusion legality check relies on DependenceInfo, which models memory
dependences purely by address and does not capture the ordering or
synchronization (synchronizes-with / fence) semantics of atomic
operations. Fusing two loops interleaves their bodies, which can reorder
atomics in ways that violate the memory model even when they touch
different locations.

Mirror the existing volatile handling and invalidate any fusion
candidate whose body contains an atomic access, adding a
ContainsAtomicAccess statistic.

This is conservative: Instruction::isAtomic() is true for unordered and
higher, so even unordered atomics (which carry no cross-thread ordering)
are rejected. This matches the all-or-nothing volatile precedent and
keeps the check simple; it can be narrowed to allow unordered later if
needed.

Fixes #193770.



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