atomic_load_unordered and atomic_store_unordered should not be used

[RalfJung]

The atomic_load_unordered and atomic_store_unordered intrinsics generate LLVM IR that cannot be mapped to the Rust AM (specifically, they cannot be represented in the C++ concurrency memory model), and as such there's no well-defined way to use them in a Rust program. Ideally we'd remove those intrinsics from the compiler. That is currently blocked on the issue that this crate uses those intrinsics.

Most of those uses seem to be to provide various intrinsics like __llvm_memcpy_element_unordered_atomic_1. Since Rust cannot use unordered atomics, those intrinsics should not be needed, right? Why do they even exist?

The other uses are in src/arm_linux.rs and src/mem/impls.rs. The latter code is already problematic for other reasons (#559). For both, I wonder if we could just use "relaxed" accesses instead, so that at least those are accesses that make sense in our memory model?

[beetrees]

Most of those uses seem to be to provide various intrinsics like __llvm_memcpy_element_unordered_atomic_1. Since Rust cannot use unordered atomics, those intrinsics should not be needed, right? Why do they even exist?

The __llvm_*_element_unordered_atomic_* intrinsics were added in #311 to unblock rust-lang/rust#59155 adding support for the relevant unordered LLVM intrinsics (feature request rust-lang/rust#58599); however that PR never got merged AFAICT.

[RalfJung]

Oh interesting, why are those unordered? That does not match rust-lang/rfcs#3301 nor the C++ proposal, to my knowledge. The bytewise atomic memcpy uses the same orderings as other atomic accesses.

[tgross35]

I believe this has been resolved with #790.