[all-commits] [llvm/llvm-project] 88c276: [InstCombine] Preserve elementwise atomic access s...

[Yonah Goldberg via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 88c276ca9da8385ceb0b343db45f9f6f4dbaf8dd
      https://github.com/llvm/llvm-project/commit/88c276ca9da8385ceb0b343db45f9f6f4dbaf8dd
  Author: Yonah Goldberg <ygoldberg at nvidia.com>
  Date:   2026-09-21 (Mon, 21 Sep 2026)

  Changed paths:
    M llvm/include/llvm/Analysis/Loads.h
    M llvm/lib/Analysis/Loads.cpp
    M llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
    M llvm/lib/Transforms/Scalar/JumpThreading.cpp
    M llvm/test/Transforms/InstCombine/atomic.ll

  Log Message:
  -----------
  [InstCombine] Preserve elementwise atomic access sizes (#223897)

There are two cases where instcombine currently will change the atomic
access size of an unordered elementwise atomic. Note that, for example,
`load atomic elementwise <4 x i32>` and `load atomic elementwise <2 x
i64>` do not have equivalent semantics. The former has 4 atomic accesses
and the latter has 2. Rewriting the former to the latter can introduce
mixed-size, concurrent, atomic accesses, which race in LLVM. Without
`elementwise`, rewriting _is_ legal.

The two cases are:

1. `mergeStoreIntoSuccessor`:

```
/// Try to transform:
///   if () { *P = v1; } else { *P = v2 }
/// or:
///   *P = v1; if () { *P = v2; }
/// into a phi node with a store in the successor.
```

You can't do this if the stores have different atomic access sizes.

2. Load CSE and load-to-store forwarding. These are also illegal if the
memory operations in question have different atomic access sizes.

Fixes https://github.com/llvm/llvm-project/issues/223738.

AI assisted.



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