Tracking Issue for WebAssembly relaxed SIMD intrinsics

[Amanieu]

Feature gate: #![feature(stdarch_wasm_relaxed_simd)]

This is a tracking issue for WebAssmbly intrinsics for the relaxed SIMD instructions.

Public API

// core::arch::wasm32

fn i8x16_relaxed_swizzle(a: v128, s: v128) -> v128;
fn i32x4_relaxed_trunc_f32x4(a: v128) -> v128;
fn u32x4_relaxed_trunc_f32x4(a: v128) -> v128;
fn i32x4_relaxed_trunc_f64x2_zero(a: v128) -> v128;
fn u32x4_relaxed_trunc_f64x2_zero(a: v128) -> v128;
fn f32x4_relaxed_madd(a: v128, b: v128, c: v128) -> v128;
fn f32x4_relaxed_nmadd(a: v128, b: v128, c: v128) -> v128;
fn f64x2_relaxed_madd(a: v128, b: v128, c: v128) -> v128;
fn f64x2_relaxed_nmadd(a: v128, b: v128, c: v128) -> v128;
fn i8x16_relaxed_laneselect(a: v128, b: v128, m: v128) -> v128;
fn i16x8_relaxed_laneselect(a: v128, b: v128, m: v128) -> v128;
fn i32x4_relaxed_laneselect(a: v128, b: v128, m: v128) -> v128;
fn i64x2_relaxed_laneselect(a: v128, b: v128, m: v128) -> v128;
fn f32x4_relaxed_min(a: v128, b: v128) -> v128;
fn f32x4_relaxed_max(a: v128, b: v128) -> v128;
fn f64x2_relaxed_min(a: v128, b: v128) -> v128;
fn f64x2_relaxed_max(a: v128, b: v128) -> v128;
fn i16x8_relaxed_q15mulr(a: v128, b: v128) -> v128;
fn i16x8_relaxed_dot_i8x16_i7x16(a: v128, b: v128) -> v128;
fn i32x4_relaxed_dot_i8x16_i7x16_add(a: v128, b: v128, c: v128) -> v128;

Steps / History

• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[Jules-Bertholet]

@rustbot label O-wasm

[RalfJung]

I am confused by the spec here. Quoting from https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md:

The same instruction at (1) and (2), when given the same inputs, can return two different results.

Okay, so that's normal non-determinism then. Wasm already has that for NaNs when there are non-canonical inputs, which is strangely not acknowledged here (has that changed?), but sure, makes sense.

Some operators are host-dependent, because the set of possible results may depend on properties of the host environment (such as hardware). Technically, each such operator produces a fixed-size list of sets of allowed values. For each execution of the operator in the same environment, only values from the set at the same position in the list are returned, i.e., each environment globally chooses a fixed projection for each operator.

This describes something else! IIUC, it says that the operation, when executed twice in the same environment, must produce the same result. In other words, the non-determinism is fixed once at program startup, and the example givejn just above actually cannot happen within a single program/module execution. This is closer to what we usually call implementation-specific behavior than to full non-determinism.

Can someone explain this seeming contradiction?