WebAssembly / WebAssembly/binaryen

Future of wasm2js

Open
#1,929 33 comments 3 reactions 0 assignees View on GitHub

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.