WebAssembly / WebAssembly/binaryen
Future of wasm2js
Nobody has claimed this yet.
- Dominant language
- WebAssembly
- Stars
- 8.6k
- Forks
- 885
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 69
Description
I'd like to do some work on wasm2js. Specifically, the use case I have in mind is to integrate it with Emscripten + the LLVM wasm backend. Then we can use that, instead of the current fastcomp asm.js backend, as a solution for emitting non-wasm output. This would have several advantages:
- Better code: Can benefit from LLVM backend opts, newer LLVM IR opts (since upstream is more up to date), Binaryen opts, and Emscripten wasm-specific opts (metadce). Will still be able to benefit from Emscripten asm.js opts, since those are in passes that run after the backend.
- Faster build times: can optionally use wasm object files for fast linking.
- No more separate bitcode or object files for two different targets.
- Get rid of fastcomp and all the support code for it.
This doesn't need to emit valid asm.js since in practice almost all browsers with asm.js AOT also have wasm anyhow (in fact chrome shipped wasm before asm.js AOT; and firefox did have some releases with just asm.js, but even LTS has had wasm for a while now). So wasm2js is an option here.
Specific work I'd like to do:
- Integrate wasm2js with emscripten.
- Benchmarking and performance tuning. Should be no slower than current fastcomp asm.js.
- Testing (emscripten test suite, almost all features should be supported) and fuzzing.
This may involve changes to the JS emitted by wasm2js, so I wanted to ask how much current wasm2js users care about the form of the output? I know the Rust people have been using wasm2js, but I heard recently they have plans to write something new (which made me sad to hear, but on the other hand fewer users may mean more flexibility in terms of how we evolve wasm2js). cc @fitzgen
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Use the proposed wasm2js and Emscripten integration as the starting scope, then review the Emscripten test suite and current fastcomp asm.js behavior. Benchmark the result against fastcomp, check feature coverage, and run fuzzing. Done means wasm2js can emit the required non-wasm output with comparable performance and broad test coverage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, wasm
- Domain
- build-system, compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100