Add LLVM atomic memcpy intrinsics, expose in core/std

[joshlf]

Expose LLVM's "element wise atomic memory intrinsics". In particular:

• Expose llvm.memcpy.element.unordered.atomic as atomic_element_unordered_copy_memory_nonoverlapping
• Expose llvm.memmove.element.unordered.atomic as atomic_element_unordered_copy_memory
• Expose llvm.memset.element.unordered.atomic as atomic_element_unordered_set_memory

Expose these through functions in the std::ptr module. Each function is implemented by the equivalent intrinsic or by a loop of relaxed atomic operations if the intrinsic is not available on the target platform (TODO: Given this platform-specific behavior, can this also be exposed in core::ptr?)

• copy_nonoverlapping_atomic_unordered, backed by atomic_element_unordered_copy_memory_nonoverlapping
• copy_atomic_unordered, backed by atomic_element_unordered_copy_memory
• write_atomic_unordered, backed by atomic_element_unordered_set_memory

Previously discussed on the internals forum here.

Folks with the authority to approve this: Let me know if this is OK to move forward; I'd like to post it to This Week in Rust's CFP.

[joshlf]

@alexcrichton Do you have thoughts on this? Want to make sure I get the go-ahead before I send somebody on TWiR's CFP down a dead end.

[alexcrichton]

I suspect there'll be opinions on stabilization, but seems fine to add as unstable at least to me!

[joshlf]

OK cool, thanks!

[tmccombs]

I'd like to take a stab at implementing this.

[joshlf]

Awesome, thanks @tmccombs ! This will unblock a lot of important work :)

[joshlf]

@alexcrichton On the subject of exposing in core::ptr: Is the ban on platform-specific logic in core a general one, or just for API-visible elements? If it's the latter, then we should be able to implement the facade in core::ptr as well.

[alexcrichton]

Currently it's largely just a "we strongly discorage platform-specific APIs" in libcore, there's already platform-specific pieces to the implementation, especially some math-related pieces on MSVC