Migrate wasm target to LLVM wasm backend

[brson]

At some point we must move rustc off the LLVM fastcomp backend. Maintaining it in sync with emcc is exceedingly burdensome. The only viable solution I see any time soon is to use the nascent LLVM wasm backend, which is not yet generally usable. I expect that we will switch to that backend, emitting wasm into rlibs instead of LLLVM IR, then link multiple wasm modules together via emcc. We may need to hack on emcc a bit to teach it to link wasm modules directly, not sure.

Even though the LLVM wasm backend is not fully working yet, somebody could go ahead and start doing the conversion and seeing what the results are like.

cc LLVM upgrade #37609

[hanna-kruppe]

re: storing wasm in rlibs and hacking emcc to make it link those, this would neatly be solved by MIR-only rlibs. That makes wasm the second backend that could use this (cc #38787) so I'm starting to think we should have an issue or something to collect these use cases. cc @michaelwoerister

[Eh2406]

What Is this up to? How does the update to LLVM 4.0 change things?

[brson]

@Eh2406 Still no progress. The LLVM 4.0 upgrade only inches us closer, but it still doesn't have a production ready backend. Since the backend does exist (I think) in the LLVM we're on, we can start enabling it for testing purposes.

[tlively]

I am currently working on using the LLVM backend behind a new target triple. The current wasm target is wasm32-unknown-emscripten, so for the new one I thought I would use wasm32-unknown-unknown. This will let us start using the LLVM backend in testing, but I was wondering what the plan is beyond that. Are we trying to remove the emscripten wasm target completely? If so, do we want to keep the asm.js target? Getting rid of both emscripten targets removes our dependency on FastComp, but if someone needs the asm.js target then this clearly isn't a possibility.

[brson]

@tlively I'd prefer to both retain the asm.js target and drop fastcomp, which I know is pretty hard; the reason being that I fear that production users will want a JS fallback for browsers missing WASM support. To achieve this ultimately I'd expect to drop fastcomp and employ a wasm->asm.js translator.

That said, wasm support is rolling out fast, so this concern may end up being unfounded.

I'd suggest the path forward should look roughly like

• Get wasm32-unknown-unknown up to feature / performance parity with wasm32-unknown-emscripten
• Replace the fastcomp backend in wasm32-unknown-emscripten with the wasm backend, leaving wasm32-unknown-asmjs in place
• Punt on the question of what to do with the asmjs target until the story becomes clearer

[tlively]

This plan sounds reasonable to me. I don't know of work on a wasm -> asm.js translator, but that sounds like a tool that could be reasonably expected to exist as wasm picks up steam.

[LukasKalbertodt]

There is some work on a wasm -> asm.js translator, named wasm2asm in the official binaryen repo. But apparently it's not that straightforward to do, as explained in the FAQ (second question).

There is also the possibility to write a wasm-interpreter in JavaScript (probably in asm.js). This seems to be supported by binaryen (click & click (search for 'interpret')), but I'm not really sure.

Get wasm32-unknown-unknown up to feature / performance parity with wasm32-unknown-emscripten

Who is working on that? How could one help? Is there an IRC channel just about the Rust-wasm story?

[tlively]

Who is working on that? How could one help? Is there an IRC channel just about the Rust-wasm story?

I am! I'm not sure how the work could be parallelized, though. There's no IRC channel or other dedicated communication that I know of, but a PR with some related discussion is #42571.

[eholk]

Maybe it's time to start the #rust-wasm IRC channel?