Does our LLVM need the fastcomp backend for emscripten?

[alexcrichton]

In #36339 we're updating LLVM to include the fastcomp backend. Upon reflection, however, I'm not actually sure if we need it in our fork of LLVM? I'm led to believe that it's our (rustc's) job to emit LLVM bytecode which emcc then slurps up and generates JS with. I'm led to believe that emcc needs and runs the fastcomp backend, but we as the Rust compiler generating bytecode otherwise wouldn't use it at all. I do believe, however, that we would need at least the definition of the asmjs target to LLVM. That is, we'd need some minor patch so it understands what the "asmjs" target is.

cc @sunfish, @kripken, does this sound right? This would certainly reduce the maintenance burden on both sides! All we'd need to do is ensure that we're both working with equivalent versions of LLVM (which shouldn't be too hard)

[kripken]

Yes, that is 100% correct. If Rust has an LLVM with the proper target triple, and emits LLVM bitcode, and Rust's LLVM is the same version as emscripten's (so the two LLVMs can swap bitcodes), then that would work. Rust would emit the bitcode, emscripten would read it, and emscripten would process it into asm.js or wasm, etc.

The user would have two copies of LLVM, which is I guess the downside.

Note that at some point the asm.js and wasm triples hope to merge. At such a time, the Rust side here could be plain vanilla LLVM, no toppings/patches. However, I'm not sure when that will be, we have some plans but not a timeline.

[alexcrichton]

@kripken awesome, thanks for the clarification!

Out of curiosity, if we do have the fastcomp backend, would it be trivial to emit JS like emcc does? Or are there tons of things that emcc does beyond running the fastcomp backend?

[kripken]

Not trivial, but possible, for limited use cases. On the one hand, the asm.js backend in fastcomp emits asm.js functions plus some metadata. You can almost just run those functions. However, it needs a little post-processing to create the asm.js module around it and set up integration with the outside (using that metadata).

But that's just for raw asm.js output. If you want integration with the web platform (e.g. to have printf print somewhere, or render graphics, or receive input, or have a virtual filesystem, etc.) then you need emscripten's JS runtime + JS libraries, which emcc links up with the backend's output. That enters into the area of "tons of things" ;)

[alexcrichton]

Ok cool, sounds like we should:

• On the next Rust LLVM update, don't re-merge fastcomp
• Figure out the "minimal" LLVM patch to teach LLVM about the asmjs target
• Land all that in the next Rust LLVM update

Thanks for the clarifications @kripken!

[brson]

I looked into this and it wasn't obvious what to do. Right now we need to pass the triples to the LLVM target registry to construct a target machine. In theory we don't need a target machine at all, but it would require some amount of surgery to make rustc understand that. So either we have to (as @alexcrichton suggested) keep a minimal LLVM patch to preserve the registry/target machine changes, or do some rustc refactoring to make the target machine optional.