-
Notifications
You must be signed in to change notification settings - Fork 797
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Predefine a few math C functions like ldexpf, even without WASI? #407
Comments
Hello, thanks for the issue! What backend are you using? Cranelift, LLVM, or singlepass? What ABI are you using: WASI ou emscripten? Thanks :-)! |
Cranelift. No ABI, just straight Wasmer. I suspect the real issue is why the Rust wasm compiler backend is generating it in the first place, and not really a wasmer issue... I was doing |
To summarize what @hrydgard commented (please correct me if I got the wasi target assumption wrong). He had Rust project that have a Right now, our wasi implementation only have the I think it should be easy to resolve in our side. |
To follow up on this. We will need to know if this is intentional when compiling Rust to the WebAssembly-WASI target or if it's a bug on the Rust WASI target (and fix it in one side or the other). |
@hrydgard to clarify, you're compiling to I am not sure if that target will correctly polyfill for You can execute functions in wasm built for the I think having some predefined imports for projects built with C or Rust is a fine idea, but we haven't come up with a good way of doing that yet. We are currently only supporting the imports defined by the ABI. |
Clarifying: Yeah, compiling to wasm32-unknown-unknown. However, I've been trying to hack https://github.com/wasmerio/wasmer-rust-example into a clean little repro, but have not yet succeeded - it works there. Will post again here if I do find a solid repro. |
It's a bug in the Rust #[no_mangle]
pub extern fn foo(a: u8) -> f32 {
2.0f32.powf(a as f32)
} when compiled as:
yields: (module
(type (;0;) (func (param f32 i32) (result f32)))
(type (;1;) (func))
(type (;2;) (func (param i32) (result f32)))
(import "env" "ldexpf" (func $ldexpf (type 0)))
(func $__wasm_call_ctors (type 1))
(func $foo (type 2) (param i32) (result f32)
f32.const 0x1p+0 (;=1;)
local.get 0
call $ldexpf)
(table (;0;) 1 1 funcref)
(memory (;0;) 16)
(global (;0;) (mut i32) (i32.const 1048576))
(global (;1;) i32 (i32.const 1048576))
(global (;2;) i32 (i32.const 1048576))
(export "memory" (memory 0))
(export "__heap_base" (global 1))
(export "__data_end" (global 2))
(export "foo" (func $foo))) so all in all this is a bug in the Rust target, we should be providing a definition of EDIT: this will be fixed once https://github.com/rust-lang/rust/pull/60491/files merges and is published in nightly for Rust |
Right, good example! I'd argue though that LLVM is in the wrong to emit a reference to such a trivial function though - it could just as well emit the few CPU instructions necessary to implement it, although that might be an optimization level thing? |
Should help in fixing wasmerio/wasmer#407
We will close this issue as soon as rust-lang/rust#60491 is merged. Thanks @alexcrichton and @hrydgard! |
Closing the issue as the side PR was just merged into Rust ( rust-lang/rust#60491 ). |
When using f32.powf(f32) from a wasm module written in Rust, an unresolved dependency is created on ldexpf.
Maybe should predefine a few functions like this? Here's a working, although not very well tested, implementation:
Or alternatively, maybe the LLVM wasm compiler should be fixed to add intrinsics for these...
The text was updated successfully, but these errors were encountered: