wasm-merge - why it has been deleted #2174
Comments
|
We deleted it because we weren't using it and weren't aware of any other uses of it. We now have support for WebAssembly object files in LLVM's lld linker, which provides a much more sophisticated way to merge wasm modules, albeit only those that are valid object files. The use case that is no longer supported is merging separate fully-linked modules together, but it seems that generally it would be better not to do that. |
|
Not all compilers use LLVM or object files though (e.g. AssemblyScript) |
|
Another issue is that it's not really been possible to merge modules without support for multiple memories. But work is underway now on multi-memory, so it might be more feasible to have a useful wasm-merge in the near future. cc @ashleynh |
|
This could still be useful for modules that don't use linear memory, or ones that have been specifically compiled to only use a certain segment of memory that won't overlap with anything else |
|
If I need to do this, what should I do? Use an older version of Binaryen? |
|
@Heath123 At the moment yes, an older version is the best option. I do think we should restore |
We used to have a wasm-merge tool but removed it for a lack of use cases. Recently use cases have been showing up in the wasm GC space and elsewhere, as people are using more diverse toolchains together, for example a project might build some C++ code alongside some wasm GC code. Merging those wasm files together can allow for nice optimizations like inlining and better DCE etc., so it makes sense to have a tool for merging. Background: * Removal: #1969 * Requests: * wasm-merge - why it has been deleted #2174 * Compiling and linking wat files #2276 * wasm-link? #2767 This PR is a compete rewrite of wasm-merge, not a restoration of the original codebase. The original code was quite messy (my fault), and also, since then we've added multi-memory and multi-table which makes things a lot simpler. The linking semantics are as described in the "wasm-link" issue #2767 : all we do is merge normal wasm files together and connect imports and export. That is, we have a graph of modules and their names, and each import to a module name can be resolved to that module. Basically, like a JS bundler would do for JS, or, in other words, we do the same operations as JS code would do to glue wasm modules together at runtime, but at compile time. See the README update in this PR for a concrete example. There are no plans to do more than that simple bundling, so this should not really overlap with wasm-ld's use cases. This should be fairly fast as it works in linear time on the total input code. However, it won't be as fast as wasm-ld, of course, as it does build Binaryen IR for each module. An advantage to working on Binaryen IR is that we can easily do some global DCE after merging, and further optimizations are possible later.
We used to have a wasm-merge tool but removed it for a lack of use cases. Recently use cases have been showing up in the wasm GC space and elsewhere, as people are using more diverse toolchains together, for example a project might build some C++ code alongside some wasm GC code. Merging those wasm files together can allow for nice optimizations like inlining and better DCE etc., so it makes sense to have a tool for merging. Background: * Removal: WebAssembly#1969 * Requests: * wasm-merge - why it has been deleted WebAssembly#2174 * Compiling and linking wat files WebAssembly#2276 * wasm-link? WebAssembly#2767 This PR is a compete rewrite of wasm-merge, not a restoration of the original codebase. The original code was quite messy (my fault), and also, since then we've added multi-memory and multi-table which makes things a lot simpler. The linking semantics are as described in the "wasm-link" issue WebAssembly#2767 : all we do is merge normal wasm files together and connect imports and export. That is, we have a graph of modules and their names, and each import to a module name can be resolved to that module. Basically, like a JS bundler would do for JS, or, in other words, we do the same operations as JS code would do to glue wasm modules together at runtime, but at compile time. See the README update in this PR for a concrete example. There are no plans to do more than that simple bundling, so this should not really overlap with wasm-ld's use cases. This should be fairly fast as it works in linear time on the total input code. However, it won't be as fast as wasm-ld, of course, as it does build Binaryen IR for each module. An advantage to working on Binaryen IR is that we can easily do some global DCE after merging, and further optimizations are possible later.
Curios why it was decided to remove
wasm-mergefrom the project? I s there any alternative "recommended way" of merging wasm modules?The text was updated successfully, but these errors were encountered: