Use atomic_element_unordered_copy_memory_nonoverlapping to read the data

[htfy96]

rust-lang/rust#58599
https://internals.rust-lang.org/t/expose-llvm-atomic-memcpy-in-intrinsics/9466/4

The volatile_read here is an questionable operation which depends on internal implementations to synchronize reads with the previous read-acquire on seqlock.

Ref: #2

[Amanieu]

AFAIK these intrinsics don't work correctly at the moment or generate poor code quality. But it's true that eventually we will want to use them.

[Rexagon]

I'm sorry for bumping an old issue, but my question seems to be related to it. How is it guaranteed that the compiler will not reoder that read after fence(Acquire)?

seqlock/src/lib.rs

Lines 133 to 141 in b72653f

	// We need to use a volatile read here because the data may be
	// concurrently modified by a writer. We also use MaybeUninit in
	// case we read the data in the middle of a modification.
	let result = unsafe { ptr::read_volatile(self.data.get() as *mut MaybeUninit<T>) };
	// Make sure the seq2 read occurs after reading the data. What we
	// ideally want is a load(Release), but the Release ordering is not
	// available on loads.
	fence(Ordering::Acquire);

As I understand the Acquire ordering means that memory reads/writes that are after that operation cannot be moved before it. But it doesn't prevent the opposite. As the comment says something like an unexisting load(Release) is needed here.

So why does it work/is it safe?