[all-commits] [llvm/llvm-project] 35227c: [RFC][LangRef] Specify that the accessed bytes of ...

[Fabian Ritter via All-commits]

  Branch: refs/heads/users/ritter-x2a/06-17-_rfc_langref_specify_that_the_accessed_bytes_of_concurrent_atomics_must_be_either_disjoint_or_the_same
  Home:   https://github.com/llvm/llvm-project
  Commit: 35227c503dcc0eccab0b65575a39c4f778c1928b
      https://github.com/llvm/llvm-project/commit/35227c503dcc0eccab0b65575a39c4f778c1928b
  Author: Fabian Ritter <fabian.ritter at amd.com>
  Date:   2026-07-10 (Fri, 10 Jul 2026)

  Changed paths:
    M llvm/docs/LangRef.md

  Log Message:
  -----------
  [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.


  Commit: 5d063c48c5d3aebebe354794b2860563c6ec7516
      https://github.com/llvm/llvm-project/commit/5d063c48c5d3aebebe354794b2860563c6ec7516
  Author: Fabian Ritter <fabian.ritter at amd.com>
  Date:   2026-07-10 (Fri, 10 Jul 2026)

  Changed paths:
    M llvm/docs/LangRef.md

  Log Message:
  -----------
  "un-simplify" the no-tearing constraint


Compare: https://github.com/llvm/llvm-project/compare/46e22fac1458...5d063c48c5d3

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