[llvm] [LangRef] Clarify what "not ordered" means in the elementwise description and reject seq_cst elementwise atomics (PR #209931)

[Sameer Sahasrabuddhe via llvm-commits]

ssahasra wrote:

Is this being actively discussed somewhere, like an RFC?

> there is no execution in which loading from flag1 in the end is NOT a data race because there is no consistent ordering of the stores of flag0 and flag1 and therefore acquiring flag0 does not give us any information on flag1.

That seems right. Is that what the model should say? Essentially we have atomics from the same thread that are not related in program order, and hence cannot be linked in happens-before.

> The problem with specifying seq_cst on elementwise atomics is that the LangRef states:
>
> >  there is a global total order on all sequentially-consistent operations on all addresses.
>
> But the individual accesses of elementwise seq_cst atomics are not consistent, which contradicts this.

Is it necessarily a contradiction? How is it different from two seq_cst operations performed by two threads? They are in _some_ order, and that order can be different for every execution. As long as all threads in a given execution agree on the order in which the `elementwise seq_cst` happened, does it matter if the instruction itself does not specify an ordering as seen by the programmer?

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