[qt/clang/llvm]: Summary of bulk changes made

Git repository change summary for qt/clang/llvm
Pushed by mirror-service into branch 'upstream/users/ritter-x2a/06-17-_rfc_langref_specify_that_the_accessed_bytes_of_concurrent_atomics_must_be_either_disjoint_or_the_same'.
Changed from b64be89ff86ab4fbf03ebb389bbaf03c72d64919 to 56e13dc6b06516cad33d4c0dd389b94b517ec0e5
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit a64f7412551ae63a49dd8617f93ab89878288879 by GitHub (on behalf of Arseniy Obolenskiy) on 20/07/2026 at 05:22..
[SPIR-V][NewPM] Register SPIRVStructurizer with the new pass manager (#209965)
https://invent.kde.org/qt/clang/llvm/-/commit/a64f7412551ae63a49dd8617f93ab89878288879

Git commit 9d2e7e6836beadbe63380f64c716df2c086ff2ea by GitHub (on behalf of Lukas) on 20/07/2026 at 06:39..
[FixIrreducible][UnifyLoopExits] Support switch statements (#206567)

This builds on #149308, which implemented `callbr` support.

The same approach of splitting multi-branch edges entering irreducible
loops can be used for switches. It does not introduce any new switch
statements, but alleviates the requirement of having to run the
`LowerSwitch` pass first. This makes the pass usable for users other
than AMDGPU, which can handle switch statements (e.g., WebAssembly, see
[here](https://github.com/llvm/llvm-project/pull/181755#issuecomment-3936316307)).

I'm also implementing a flag into the `ControlFlowHub` to support
switches as well, for which I will open a separate PR. Currently the
`ControlFlowHub` creates a branch-sled, mimicking a `switch` (a series
of blocks consisting only of conditional branches, selectively entering
an irreducible loop at a certain point or continuing to the next
potential entry point). If the target can support switches, that should
be the clear goal here, as shown in the image below. This PR implements
the step from (a) to (b), whereas extending the `ControlFlowHub`
represents the step from (b) to (c). ((c) to (d) already exists through
`SwitchToLookup` and `SwitchToArithmetic`).

<img width="1055" height="432" alt="image"
src="https://github.com/user-attachments/assets/780b7894-1895-4137-8148-b2bbc7f73a8f"
/>

The test cases in `switch.ll` were adapted from the `callbr.ll` tests
using an LLM to ensure equivalent coverage. I've manually reviewed the
control flow and conditions for every case, and the final assertions
were generated using `update_test_checks.py`.
https://invent.kde.org/qt/clang/llvm/-/commit/9d2e7e6836beadbe63380f64c716df2c086ff2ea

Git commit d8f7ce063cf04133f446e078e6f02126ac8dc79f by Fabian Ritter on 20/07/2026 at 06:41..
[RFC][LangRef] Specify that the accessed bytes of concurrent atomics must be either disjoint or the same

So far, the LangRef hasn't been clear on the semantics of partially overlapping
concurrent atomics in LLVM IR (specifically: a set of accesses marked as
`atomic` that would be in a data race if they weren't `atomic` and not all of
them access the exact same set of bytes).

What loads read is defined in terms of individual bytes, but the memory
ordering constraints are formulated closely to the C/C++ (and Java for
`unordered`) memory model, where partially overlapping atomics are not
possible. It's not obvious how concepts like C/C++'s per-location total
modification order for `monotonic` accesses map to accesses that can partially
overlap. While C/C++ relies on the modification order to ensure that atomics
cannot tear (i.e., atomic reads return bytes from two or more atomic writes),
our IR semantics (as written) currently does not guarantee this in the presence
of partially overlapping accesses.

This PR proposes a solution to this problem: It specifies that concurrent
overlapping atomics must access the exact same set of bytes to act atomically.
If they don't, they form a data race (i.e., participating loads read `undef`
for affected bytes). This empowers the rest of the specification to imply that
`monotonic` (or stronger) accesses do not tear. The PR also adds a constraint
to ensure non-tearing for `unordered` atomic accesses.

This solution implies that transformations that merge adjacent atomic
loads/stores into wider atomic loads/stores are generally incorrect.
https://invent.kde.org/qt/clang/llvm/-/commit/d8f7ce063cf04133f446e078e6f02126ac8dc79f

Git commit 29a08b541c739bb671757d9312658f9209ac0573 by Fabian Ritter on 20/07/2026 at 06:41..
"un-simplify" the no-tearing constraint
https://invent.kde.org/qt/clang/llvm/-/commit/29a08b541c739bb671757d9312658f9209ac0573

Git commit dcb93429a67e45c971a0b1b21ac1636bb33bada4 by Fabian Ritter on 20/07/2026 at 06:41..
Adapt Ralf's simpler no-tearing formulation.
https://invent.kde.org/qt/clang/llvm/-/commit/dcb93429a67e45c971a0b1b21ac1636bb33bada4

Git commit 222d484e6820cb4ee665f6012aeb61c83108068c by Fabian Ritter on 20/07/2026 at 06:41..
Remove vague use of "defined"
https://invent.kde.org/qt/clang/llvm/-/commit/222d484e6820cb4ee665f6012aeb61c83108068c

Git commit 56e13dc6b06516cad33d4c0dd389b94b517ec0e5 by Fabian Ritter on 20/07/2026 at 07:36..
Explicitly restrict the atomic ordering constraints to perfectly overlapping accesses.
https://invent.kde.org/qt/clang/llvm/-/commit/56e13dc6b06516cad33d4c0dd389b94b517ec0e5