[buu700]

Ah okay, interesting. Is it because wasm doesn't yet add any new functionality over asm.js that using asm.js as an intermediary step isn't inherently worse?

In that case, it sounds like the LLVM backend will only yield clear user-facing benefits when new features like pthreads are introduced?

[azakai]

Well, the "asm.js to wasm" path actually isn't pure asm.js anymore. We added i64 support and other things a while back, as intrinsics. So the asm2wasm path isn't limited by asm.js. It's weird ;) but it produces good code...

The wasm backend does have other benefits, which is why we'd like to move emscripten to use it by default:

* It uses LLVM's default legalization code, so it can handle LLVM IR from more sources (i.e. not just C and C++ from clang).

* We can stop maintaining the out-of-tree LLVM that asm2wasm depends on.

The LLVM wasm backend isn't ready yet (larger output code, slower compile times, a few missing features) but it's getting there.