Allow volatile accesses to trap

[RalfJung]

I think we should allow all volatile accesses to trap. The reasons are summarized well by @nikic in llvm/llvm-project#192992:

• This gives a well-defined (if not very ergonomic) way to interact with potentially trapping memory.
• It is what C will apparently do in future versions of the standard, and it would IMO be bad if Rust had stricter requirements than C in this space.

This would in particular mean that volatile accesses are "UB barriers" in the sense that UB happening after a volatile operation cannot affect what the program does before that operation.

@rust-lang/opsem any objections, or should be move this to FCP?

To actually implement this:

• For stores, we just have to change the docs. LLVM already considers those not-willreturn and hence treats trapping stores correctly.
• For loads, we have to either wait until we have a version of LLVM that includes this PR, or we have to find some way to adjust our volatile load lowering that removes the willreturn assumption on the LLVM side.

[CAD97]

The rationale seems convincing enough to me. And the implementation approach of waiting on LLVM to address this seems reasonable.

As a side effect, this also makes volatile better fit the mental model of "access with observable side effects," as removing willreturn moves the volatile accesses much closer to being behaviorally equal to a foreign function call w.r.t. what the Rust-side optimizations can assume.

Aside: does this change effectively mean that we can treat volatile writes as atomically sequenced with other volatile writes in the same thread? The MMIO commit use case prefers memcpy(...); atomic_volatile_write(..., Release), but a simple(?) volatile_memcpy(...); volatile_write(...) working as probably intended would be quite nice.

[RalfJung]

No, volatile accesses remain non-atomic and hence cannot have release/acquire semantics.