Allow volatile accesses to trap

[RalfJung]

I think we should allow all volatile accesses to trap. This gives a well-defined (if not very ergonomic) way to interact with potentially trapping memory. LLVM already made this change, we just have to expose it.

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. It seems like C will specify this for all observable events in the future; it would be bad if Rust had more footguns here than C does.

@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. :)

[ais523]

Just to add an additional use-case that supports this change: some programs may want to intentionally cause traps using volatile accesses. (After all, a trap is a side effect of a read or write, so if you want to do one intentionally, you would want to use a volatile access in order to prevent it being optimised out.)

A good example is stack probes, which (when the stack expands by a large amount at once) access one byte on every page between the old and new stack size; this is combined with a memory layout designed to place at least one page of trapping memory in between the stack and any other memory used by the program. The effect is to create a bounds check that the stack has not grown too large (and it is possible to handle the resulting trap and react to it, e.g. by allocating more stack memory or printing a message about stack overflow). Although Rust automatically inserts stack probes for the main hardware stack, the same technique could reasonably be used for other growing buffers of memory, and in that situation you would need a volatile read/write to consistently block the execution of code beyond it (which could be an out-of-bounds write that was supposed to have been prevented by the stack probe).

It hadn't crossed my mind that the abstract machine might not allow this use of volatile, because to me it's one of the things that volatile should be intended to do.

[robofinch]

Just checking for clarity, I assume this would mean that ptr::read_volatile::<u8>(ptr::without_provenance(0x12345)) (where the read causes a segfault, rather than having some other special hardware meaning) is not UB?

[RalfJung]

If the read causes a segfault that aborts the process then yes that's allowed under this PR.

If the address lies within Rust AM memory then the call is UB since you must not access Rust AM memory using no-provenance pointers.

[chorman0773]

We should separate the idea of trapping volatile accesses from UB time-traveling.
The fact that volatile accesses can trap is an effective prerequisite, but not a deciding factor, of time traveling UB. I'm notably interested in what happens in the xLTO case where foreign IO/volatile is marked explicitly willreturn (or equivalent), and that inference reaches optimizations done on rust code without knowledge of the body. That seems like precluding time-travelling UB would mean such functions cannot be modeled as having Rust AM side effects.
Also, does llvm treat volatile reads/writes to deferenceable pointers are willreturn still? I certainly would want to.

[RalfJung]

We should separate the idea of trapping volatile accesses from UB time-traveling.

Yes that's why there are two separate PRs for these two points (rust-lang/reference#2320, rust-lang/rust#160564).

Also, does llvm treat volatile reads/writes to deferenceable pointers are willreturn still? I certainly would want to.

It could, but I don't think it does.