binaryen.js wasm-opt commandline tool

WebAssembly / binaryen

Optimizer and compiler/toolchain library for WebAssembly

Apache License 2.0

7.5k stars 744 forks source link

binaryen.js wasm-opt commandline tool #2411

Open kripken opened 5 years ago

kripken commented 5 years ago

Currently binaryen.js provides a JS API. Maybe we could also make a commandline version, basically a port of wasm-opt so it runs in node.js. Using NODERAWFS it can have filesystem access, and using node pthreads it even should be almost as fast.

I'm imagining something like

$ npm install -g binaryen
$ wasm-opt input.wasm -O -o output.wasm

This might help with distributing builds. See e.g. https://github.com/WebAssembly/binaryen/pull/2405#issuecomment-548529341 for issues with getting a single native build to run on all linuxes etc. - with a node.js build we should be easily portable to anywhere node.js runs + more secure! :)

cc @dcodeIO

MaxGraey commented 5 years ago

also will be great have WebAssembly backend for binaryen.js

dcodeIO commented 5 years ago

The binaryen.js package has some super basic CLI utilities already that can't do much (more a proof of concept I made long ago because why not) named binaryen-as, binaryen-dis and binaryen-opt. Providing proper ones would be a lot better ofc. so count me in :)

kripken commented 5 years ago

@dcodeIO oh nice! Yeah, that's the same idea basically.

I wonder if just porting existing wasm-opt, instead of writing a new JS frontend, would allow more functionality. However, maybe those JS frontends are already good enough for most things? Would be nice to document them on https://www.npmjs.com/package/binaryen perhaps.

If I have time I might look into a full wasm-opt port, but not sure when I will. If someone else wants to that would be great.

dcodeIO commented 5 years ago

Some thoughts:

Compiling the tools from C++ pretty much guarantees that everything is in sync, like --help messages with all the current passes, and as feature complete as it gets, so this has its benefits.
But: Can we make it so that the CLI tools depend on binaryen.js by means of require etc. to minimize package size? Let's say we'd ship wasm-as, wasm-dis and wasm-opt, that'd otherwise mean three additional like ~4mb JS files for a CLI feature not everyone needs.
Since you mentioned threading support: Is this already the case with normal binaryen.js as a library? If not, would it be possible to make the library itself feature-detect let's say node pthreads and use it if available?

kripken commented 4 years ago

@dcodeIO

Would be good to find a way to make the builds depend on each other, yeah. Maybe a single build of wasm-opt + the binaryen C API would be enough, as those exports should provide everything.

About threads, binaryen.js is built without them, but in theory it should work with node pthreads. I didn't try that though. However, a pthreads build would need to be another build, as it will not validate in a VM without pthreads support.

dcodeIO commented 4 years ago

I see, hmm.

Maybe a single build of wasm-opt + the binaryen C API would be enough, as those exports should provide everything

Makes me wonder if the tools could be refactored to use the C-API exclusively, which is exported by binaryen.js in its entirety anyway, and somehow link with it dynamically? That'd be ideal if possible since all parts have minimal size.

If that's not possible I guess we could still do a @binaryen/cli package, so package size is not a concern and it's fine to link everything statically? Likewise, perhaps a @binaryen/node package with pthreads?

tlively commented 4 years ago

It seems that if we take this refactoring to the extreme, we would end up with 1) a core Binaryen library, 2) A barebones CLI pass runner 3) separate modules for each pass.