Linking wasm modules with wasm-merge ?

[le...@grame.fr]

Hi,

Our Faust compiler (faust.grame.fr) can directly generate wasm modules from the Faust DSP source code. We typically generate modules that need mathematical functions (log, sin, pow...) which are imported from the JS context (by generating the appropriate module "import" section). 

We would like to test our Faust generated wasm code using more optimized mathematical functions (so using a fast_log, fast_sin, fast_pow versions of the functions). Those functions are coded in a C++ file, then compiled as a wasm module using emcc -O3 -s WASM=1 -s SIDE_MODULE=1 fastmath.cpp -o fastmath.wasm.

Then we tried to link the fastmath.wasm module using the wasm-merge tool, so doing (for a given pre-compiled Faust DSP filterBank.wasm module) : wasm-merge filterBank.wasm fastmath.wasm, but we get the error : "Fatal: no memory base was imported" 

1) is the wasm-merge tool ready for that kind of use case? If yes how it should be used?

2) will the wasm-merge code be part of the binaryen.js library, so that liking wasm modules could possibly dynamically be done in a Web page, or used in nodejs context for instance ?

Thanks.

[Alon Zakai]

We should support both 1 and 2, not hard, just hasn't been done yet.

But first, let me ask about your use case: the "no memory base was imported" message is too general (we should fix that), but it is there because if there isn't a memory base, then memory isn't relocatable, and we can't merge memories. So that can only work if the modules don't have memory segments. Is that the case for you, it's just code, not data?

If you don't have data, then as a temporary workaround you can just import the relocatable offsets, adding

  (import "env" "memoryBase" (global $memoryBase i32))
  (import "env" "tableBase" (global $tableBase i32))

But we should also make it work if those don't exist, assuming there is no data.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[le...@grame.fr]

Both modules have memory segments.

By asking the lines   (import "env" "memoryBase" (global $memoryBase i32)) and  (import "env" "tableBase" (global $tableBase i32)) in our generated oddly, the wasm-merge runs without errors.

But I'm still not clear in how functions exported by one module (the fastmath version of math functions) can be imported (= used) but the other one? Is that possible?

Thanks.

[Alon Zakai]

Oh, they have memory segments - do you ensure they don't collide manually? No need for runtime relocations? The merger should just work on that, but it can't check for errors on it.

The merger resolves imports and exports, if one module exports A and the other imports env.A, then in the merged module that import becomes something in the module that is called directly. This does make the assumption that exports are on "env", which is the convention (wasm imports/exports are a little odd in that imports have two components but exports have one). See for example

https://github.com/WebAssembly/binaryen/blob/master/test/merge/fusing.wast

which merged with

https://github.com/WebAssembly/binaryen/blob/master/test/merge/fusing.wast.toMerge

results in

https://github.com/WebAssembly/binaryen/blob/master/test/merge/fusing.wast.combined

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[le...@grame.fr]

OK. I'll have to checkout for memory segments. And I had to change the import naming convention off our generated module to use "env". Now "call  merge" are correctly generated.

One issue still. The "fastmath" C++ module has 2 set of functions, one using "float" type and one using "double". The code is compiled with emcc -O3 -s WASM=1 -s SIDE_MODULE=1 xxx but the generated wast/wasm still uses f64 type even for  "float" versions (doing float/double cast...). Why is that? Is there a way to correctly general f32 versions of the function when the original C++ code is using "float" ?

Thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alon Zakai]

I think emscripten's LEGALIZE_JS_FFI option can help there, -s LEGALIZE_JS_FFI=0 will make it not emit asm.js-compatible function types, so it should have normal f32s.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[le...@grame.fr]

Thanks, that works well. 

Now the 2 modules can be properly linked with wasm-merge and the resulting one compiled and instantiated in JS context.

Next problem is this kind of error when running it : "RuntimeError: index out of bounds"  when calling (for instance...) the fast_log10f function of the following code compiled to wasm with emcc 1.17.21 : https://raw.githubusercontent.com/grame-cncm/faust/master-dev/architecture/faust/dsp/fastmath.cpp

Is there any specific precautions to take when compiling the fastmath.cpp code ? Range issues ? Anything else?

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alon Zakai]

Hmm, wasm does trap on some float-to-int overflows and things like that, but "index out of bounds" sounds like a memory access error - could be a bug in the code being compiled. If it doens't look like that, I can debug a testcase if you have one.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[le...@grame.fr]

The problem was in my code. I succeeded running the final wasm-merged code in the browser. But beside very simple cases where I see a gain, using this emcc compiled fast-code code merged with the Faust generated wasm modules shows big regressions (like 2 to 4 times slower...), I don't understand why ... Any hypothesis ?

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alon Zakai]

I don't know enough details here - what is 2 to 4 times slower, what are the two scenarios being compared?

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.