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

[Ralf Jung via llvm-commits]

================
@@ -4057,12 +4057,18 @@ Given that definition, R{sub}`byte` is defined as follows:
 -  Otherwise, if R{sub}`byte` may see exactly one write,
    R{sub}`byte` returns the value written by that write.
 -  Otherwise, if R is atomic, and all the writes R{sub}`byte` may
-   see are atomic, it chooses one of the values written. See the {ref}`Atomic
+   see are atomic, and R and the writes all access the exact same set of
+   bytes, it chooses one of the values written. See the {ref}`Atomic
    Memory Ordering Constraints <ordering>` section for additional
    constraints on how the choice is made. Targets may impose additional
    requirements on R and the writes it may see based on their `syncscope`.
 -  Otherwise R{sub}`byte` returns `undef`.
 
+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`,
----------------
RalfJung wrote:

Oh, of course.

I find it kind of confusing how this defines first the per-byte accesses and then needs this no-tearing clause when combining them to whole accesses. But that's how the entire docs are already written so 🤷 .

I am a bit concerned about the case where byte 0 can see W1 and W2, and byte 1 can see W1 and W3. It seems like your definition would allow the sub-reads to use different writes. But maybe that situation cannot arise because it would have been a write-write race somewhere before already?

I think under the UB you have, your definition is equivalent to the following that I find easier to understand -- or did I miss something?
> Defined atomic accesses cannot tear: If a byte subaccess R{sub}`byte1` of
an atomic read R reads from W{sub}`1`, then all other byte subaccesses R{sub}`byte2` of R that can see  W{sub}`1` must also read from W{sub}`1`.

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