sqrt is provided for wasi but not wasm32-unknown-unknown

[Lokathor]

Right now the list of no_mangle symbols for wasm32-unknown-unknown doesn't include sqrt. However, the wasi target does expose sqrt. Since a properly compiled sqrt on wasm32 of any type compiles down to a single wasm instruction, I'm not sure why sqrt is exposed for wasi and not for wasm32-unknown-unknown.

This same question applies to any other libm function that's part of wasi but not parts of wasm32-unknown-unknown, though there's so many libm functions i'm not sure of the full list at this time.

[alexcrichton]

This crate only is here to supply what LLVM generates references to, and LLVM doesn't generate references to a sqrt symbol, so it's not necessary.

The libm intrinsics themselves sometimes call sqrt, so the libm::sqrt function is transitively reachable via the other exposed intrinsics on the wasm32-unknown-unknown target. That's why it's optimized in libm. On wasi the C library provides the symbols instead of this crate.

[Lokathor]

Ensuring full compiler-builtins support was listed as a general step in the tracking issue shown above towards the process of adding floating point functions into core.

rust-lang/rust#50145 (comment) for the exact comment.

Are you saying that, at least for this particular intrinsic, the compiler-builtins step can be considered "complete" and we could move on to the next step?

[gnzlbg]

Ensuring full compiler-builtins support was listed as a general step in the tracking issue shown above towards the process of adding floating point functions into core.

@Lokathor as @alexcrichton mentions, we don't need to add anything here to add support of the sqrt function to core for this target. libcore can just call the llvm intrinsic on this platform, and no symbol will ever be generated, so adding something here doesn't solve any problems.

[Lokathor]

Okay, cool. I will proceed in the main tracking issue then.