[all-commits] [llvm/llvm-project] eb2ae5: [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: eb2ae542690113d0db470b9e1d58725cef74dbfa
      https://github.com/llvm/llvm-project/commit/eb2ae542690113d0db470b9e1d58725cef74dbfa
  Author: Fabian Ritter <fabian.ritter at amd.com>
  Date:   2026-07-14 (Tue, 14 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: e0dcab4ba2a4d6707bc6acc5764bea863e64d0f7
      https://github.com/llvm/llvm-project/commit/e0dcab4ba2a4d6707bc6acc5764bea863e64d0f7
  Author: Fabian Ritter <fabian.ritter at amd.com>
  Date:   2026-07-14 (Tue, 14 Jul 2026)

  Changed paths:
    M llvm/docs/LangRef.md

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


  Commit: 454bb24df08625be70b59d9a2e23c5f03e3812c1
      https://github.com/llvm/llvm-project/commit/454bb24df08625be70b59d9a2e23c5f03e3812c1
  Author: Fabian Ritter <fabian.ritter at amd.com>
  Date:   2026-07-14 (Tue, 14 Jul 2026)

  Changed paths:
    M llvm/docs/LangRef.md

  Log Message:
  -----------
  Adapt Ralf's simpler no-tearing formulation.


Compare: https://github.com/llvm/llvm-project/compare/5d063c48c5d3...454bb24df086

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