binaryen.js wasm-opt commandline tool

[kripken]

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. #2405 (comment) 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]

also will be great have WebAssembly backend for binaryen.js

[dcodeIO]

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]

@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]

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]

@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]

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]

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.