Repository navigation
Tracking Issue for WebAssembly relaxed SIMD intrinsics #111196
Description
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)1
- Stabilization PR
Unresolved Questions
- None yet.
Footnotes
Reacted by Till Ulen
Activity
Jules-Bertholet commentedon May 5, 2023
@rustbot label O-wasm
RalfJung commentedon Nov 1, 2023
I am confused by the spec here. Quoting from https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/Overview.md:
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.
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?
Auto merge of rust-lang#117468 - daxpedda:wasm-relaxed-simd, r=wesley…
Rollup merge of rust-lang#117468 - daxpedda:wasm-relaxed-simd, r=alex…
Auto merge of rust-lang#117468 - daxpedda:wasm-relaxed-simd, r=alexcr…