Rollup merge of #73036 - alexcrichton:update-wasm-fence, r=Mark-Simulacrum

std: Enable atomic.fence emission on wasm32

This commit removes the `#[cfg]` guards in `atomic::fence` on wasm
targets. Since these guards were originally added the upstream wasm
specification for threads gained an `atomic.fence` instruction, so LLVM
no longer panics on these intrinsics.

Although there aren't a ton of tests in-repo for this right now I've
tested locally and all of these fences generate `atomic.fence`
instructions in wasm.

Closes #65687
Closes #72997
This commit is contained in:
Dylan DPC 2020-06-12 00:05:27 +02:00 committed by GitHub
commit 3b41e54799
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -2623,15 +2623,7 @@ unsafe fn atomic_umin<T: Copy>(dst: *mut T, val: T, order: Ordering) -> T {
/// [`Relaxed`]: enum.Ordering.html#variant.Relaxed /// [`Relaxed`]: enum.Ordering.html#variant.Relaxed
#[inline] #[inline]
#[stable(feature = "rust1", since = "1.0.0")] #[stable(feature = "rust1", since = "1.0.0")]
#[cfg_attr(target_arch = "wasm32", allow(unused_variables))]
pub fn fence(order: Ordering) { pub fn fence(order: Ordering) {
// On wasm32 it looks like fences aren't implemented in LLVM yet in that
// they will cause LLVM to abort. The wasm instruction set doesn't have
// fences right now. There's discussion online about the best way for tools
// to conventionally implement fences at
// https://github.com/WebAssembly/tool-conventions/issues/59. We should
// follow that discussion and implement a solution when one comes about!
#[cfg(not(target_arch = "wasm32"))]
// SAFETY: using an atomic fence is safe. // SAFETY: using an atomic fence is safe.
unsafe { unsafe {
match order { match order {