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

[James Y Knight via llvm-commits]

jyknight wrote:

> 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.

That's the fundamental issue: the stores _aren't_ necessarily "in some order".

Here's the usual independent-writers/independent-readers memory-model litmus test:
```
// Initial state: flag0=0, flag1=0

// Thread 1
store atomic seq_cst flag0, 1

// Thread 2
store atomic seq_cst flag1, 1

// Thread 3:
r1 = load atomic seq_cst flag0
r2 = load atomic seq_cst flag1

// Thread 4:
r3 = load atomic seq_cst flag1
r4 = load atomic seq_cst flag0
```

The total ordering specified for seq_cst explicitly *prohibits* seeing the following outcome from a single execution:
- r1=1 and r2=0, indicating that Thread3 observes flag0 set before flag1
- r3=1 and r4=0, indicating that Thread4 observes flag1 set before flag0.

For any of the other memory orders, that outcome may occur.

Now, consider if we replace Thread 1 and Thread 2 with a single thread executing:
`store elementwise atomic seq_cst [flag0, flag1] , <1, 1>`.

Under the current spec -- and if we codegen the elemetwise atomic as something like: `fence; store; store; fence`, without internal fencing between the stores -- then we _can_ observe that outcome.

IMO, it's _plausible_ that a concept of unordered sub-pieces of a seq_cst otherwise-total ordering could successfully be described and added to the memory model. But we don't currently have any such specification, nor a proper understanding of the consequences to the model if we were to attempt to do so.

So, absent further research on this topic, and since there's no known use-case, the best option is to prohibit the possibility.

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