[llvm] [RFC][LangRef] Specify that the accessed bytes of concurrent atomics must be either disjoint or the same (PR #204329)

[Fabian Ritter via llvm-commits]

ritter-x2a wrote:

>[...] fully defining mixed-size atomics [...] adds a _ton_ of additional complexity to an area which is already terribly complex. 

I agree with that: fully defined mixed-size atomics add a lot of complexity to the spec that makes it harder to understand for humans (and significantly more complex to model and analyze in a mechanized formal setting).

> If I understand jyknight correctly, then we should not make the following addition:
> 
> > * Otherwise, if R is atomic, all the writes R\ :sub:`byte` may
> >   see are atomic, **and R and the writes all access the exact same set of
> >   bytes,** it chooses one of the values written. [snip]
> > * Otherwise R\ :sub:`byte` returns `undef`.
> 
> But we should keep the following addition:
> 
> > Defined atomic accesses cannot tear: Two byte subaccesses
> > R\ :sub:`byte1`, R\ :sub:`byte2` of an atomic read R cannot read from
> > different atomic writes W\ :sub:`1`, W\ :sub:`2` if both read
> > subaccesses, R\ :sub:`byte1`, R\ :sub:`byte2`, may see both writes,
> > W\ :sub:`1`, W\ :sub:`2`.
> 
> The first one causes a concurrent mixed-size atomics to fall through to the next `undef` clause. The second merely says that atomics that specify the same location cannot tear. Is that correct? Is the second dependent on the first in any way?

I don't think that's quite everything.
- Yes, we'd need to drop the "and R and the writes all access the exact same set of bytes" requirement for avoiding undef reads.
- The second addition should still be fine to ensure that non-partially-overlapping atomics (unordered and stronger) act atomically. It additionally puts a few limitiations on what kinds of tearing partially overlapping concurrent accesses can observe (but not enough to rule out tearing entirely, see the example below). That might be fine, or we could make this spec addition conditional on "If the involved accesses access the same set of bytes, ..." to avoid the unnecessary(?) restriction.
- We also need some clarifications in the "Atomic Memory Ordering Constraints" section:
    - "there is a single total order for modifications by ``monotonic`` operations **with the same access size** on each address." (bold words to be added). The other sentences about monotonic might also need some wording changes to take into account that only non-partially-overlapping accesses are ordered.
    - release/acquire also need a requirement that the read and write that establish synchronization must access the same set of bytes (that also needs to be clear in the section about the fence instruction; arguably the C/C++ lingo used there already implies that: "both operating on some atomic object M". It's however a different kind of problem that this lingo isn't used anywhere else in the LangRef, so I'd say clarification there would be useful.)
    - Something needs to be done with seq_cst as well. Maybe we can relax the requirement that the order of seq_cst operations must be total and state that seq_cst operations that overlap partially don't have to be ordered? Making that fit with the referenced C++ spec is certainly scary.

Then, partially overlapping atomics can tear, for example: Say we have two atomic writes W01, W12 (writing locations 0, 1 and 1, 2, respectively) and an atomic read R012 (reading locations 0, 1, 2).
If W01 happens-before W12 (e.g., because they are program-ordered in the same thread), and R012 is not in hb with either of them, R012 is allowed to read the values from W01 at locations 0, 1 and the value from W12 at location 2 (meaning it partially observes W12).
As I understand, that is intended with this proposal.

---

Overall it's doable (assuming we'd find a satisfying way to handle seq_cst). I'll note that the solution proposed in this PR comes with a smaller diff than the above proposal.

https://github.com/llvm/llvm-project/pull/204329