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.
On Sat, Nov 25, 2017 at 3:54 AM, <[email protected]> wrote: > 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. > > Le samedi 25 novembre 2017 03:33:09 UTC+1, Alon Zakai a écrit : >> >> 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 >> >> >> On Thu, Nov 23, 2017 at 6:22 AM, <[email protected]> wrote: >> >>> 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. >>> >>> Le mercredi 22 novembre 2017 19:08:03 UTC+1, Alon Zakai a écrit : >>>> >>>> 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. >>>> >>>> >>>> On Wed, Nov 22, 2017 at 2:20 AM, <[email protected]> wrote: >>>> >>>>> 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. >>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> 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 [email protected]. >>> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
