[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:

> So...I've realized that we've also created a very similar specification issue with the introduction of "elementwise" atomicrmw, and soon load/store.
> 
> The "elementwise" attribute specifies that the operations are internally unordered. So, `store ptr %p, <2 x i32> %value seq_cst` stores 2 i32s, as if by `store ptr %p, i32 %val1 seq_cst; store ptr %p, i32 %val2 seq_cst`, _except that_ those two stores are _unordered_ w.r.t. each-other! But, what that actually means needs to be nailed down...
> 
> This is, I believe, the exact same thing we need to nail down for the individual _bytes_, in cases where we allow tearing.

This seems like less of a problem for the `elementwise` modifier to me.
An `atomicrmw` with `elementwise` "behaves as if it were expanded into one scalar `atomicrmw` per element"; I understand that as meaning for an `atomicrmw elementwise seq_cst` that the seq_cst order relates the individual atomic subaccesses, not the full vector access. A valid execution's seq_cst order must order the subaccesses in some way; it doesn't matter which way. Notably, other operations from other threads can be ordered between the individual subaccesses in the seq_cst order.

That's different from the situation we'd have here, where, if we define this new state of bytewise atomicity, the user has still requested that the full access is somewhere in the seq_cst order.

---

Sidenote regarding `elementwise`'s interaction with this PR's proposal: the individual atomic subaccesses would be the accesses whose accessed bytes need to match exactly with competing accesses. Therefore, dropping `elementwise` from an atomic would be illegal:
-  A `store atomic elementwise ptr %p <2 x i32> ...` that is hb-unordered with a `store atomic ptr %p i32 ...` is fine (the accessed bytes of one of the subaccesses are the same as the accessed bytes of the non-vector access);
- a `store atomic ptr %p <2 x i32> ...` that is hb-unordered with a `store atomic ptr %p i32 ...` is a data race (the accessed bytes of the vector access overlap partially with those of the non-vector access).

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