Tracking Issue for Wasm floating point instructions not in `core`

[daxpedda]

Feature gate: #![feature(wasm_numeric_instr)]

This is a tracking issue for floating point instructions that aren't available in core but are available as simple instructions on Wasm directly.

Public API

mod arch {
    mod wasm32 {
        pub fn f32_ceil(a: f32) -> f32;
        pub fn f32_floor(a: f32) -> f32;
        pub fn f32_trunc(a: f32) -> f32;
        pub fn f32_nearest(a: f32) -> f32;
        pub fn f32_sqrt(a: f32) -> f32;
        pub fn f64_ceil(a: f64) -> f64;
        pub fn f64_floor(a: f64) -> f64;
        pub fn f64_trunc(a: f64) -> f64;
        pub fn f64_nearest(a: f64) -> f64;
        pub fn f64_sqrt(a: f64) -> f64;
    }
}

Steps / History

• Implementation: Add numeric instructions for Wasm not available in core stdarch#1677
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

My impression from #50145 was that these methods (except sqrt()) are not intended to ever be added to core. But looking at a recent discussion in Zulip it paints a different picture.

If indeed these methods are intended to come to core, then these additions will probably never be stabilized.

Footnotes

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

[hanna-kruppe]

I would like to have these available on stable as soon as reasonably possible. Of course having them available in no_std on all platforms would be even better, but if that stalls out again (it’s not a new topic) then I don’t see the harm in stabilizing some arch intrinsics that will become redundant at some point in the future. We also have _mm_sqrt_ss on x86 (explicitly used by libm today!) and a bunch of other arch intrinsics that are technically redundant even with current core capabilities (e.g., basic SIMD loads and stores can be done with ptr.{read,write}{,_unaligned}).

[daxpedda]

Hereby requesting an FCP.

Stabilization PR: rust-lang/stdarch#1700.
Cc @Amanieu, you were against stabilizing this in favor of having these functions in core.
Cc @alexcrichton for being the target maintainer.

@rustbot label +I-libs-api-nominated

[daxpedda]

@tgross35 pointed out in Zulip that bringing these functions to core is already a WIP, which would make the additions here redundant.

[hanna-kruppe]

Note that the implementation of these functions in libm now uses the core::arch::wasm32 intrinsics covered by this tracking issue. They could be kept unstable indefinitely, but that seems a slightly unusual location for perma-unstable implementation details of core. The alternative is to remove the core::arch versions and revert rust-lang/libm#418 - what do you think @tgross35? (I assume inline assembly is undesirable because it prevents some optimizations.)