Allow volatile accesses to trap / no time-traveling UB

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

Also see #407.

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

[RalfJung]

Based on discussion with @nikic, this is all that remains for us to declare that UB is not time-traveling.

The other part is to not park functions as willreturn if they do I/O. That might need documentation updates for the ffi_pure attribute and inline asm, but it should be fine.

So... we just have to wait until LLVM gets bumped to include llvm/llvm-project#192992 (LLVM 23?), then we can finally resolve that. :)