Another useful task would be to get the asmjs target working without the big LLVM fastcomp backend (https://github.com/rust-lang/rust/issues/36356). We actually don't need the pnacl legalizer or the asmjs code generator, since we just pass bitcode to emcc which then uses those backends to generate asmjs. But rustc does currently call the LLVM TargetRegistry, passing the asmjs triple, so that LLVM can tell us the right TargetMachine to create. It's not clear that rustc even needs to create a TargetMachine at all for what we are doing. There are two possible solutions here: delete all the LLVM fastcomp code except that which supports the TargetRegistry; make rustc work without instantiating a TargetMachine.
Myself, I'm still poking at the unwinder(https://github.com/rust-lang/rust/issues/36514), and in turn enabling errors on unimplemented symbols (https://github.com/rust-lang/rust/issues/36515). I pushed a patch to the PR that implements unwinding on top of the C++ APIs that emscripten already suppports and it works in cursory testing. I also have an action item to get the automation set up in our dev environment, but haven't started.
What does it mean for exception handling performance to be bad in asm.js? Is it the runtime performance of unwinding and catching exceptions or the bloat associated with the landing pads? Does unwinding impose overhead on the non-unwinding path? I imagine it's similar to the native case; unwinding is just always expensive in code size and run time, but I have seen some decompiled asm.js that looks like there may be extra book-keeping on the non-unwinding path, which would certainly be unattractive.
Unwinding is part of the Rust semantics and we need to support it for the test suite to work in any reasonable fashion if nothing else (otherwise every test would simply abort on failure, which makes for an unpleasant debugging experience when there are multiple test failures). I expect
-C panic=abort to work for asmjs targets similarly to others so those that don't want unwinding don't need to pay the cost, and I'd expect most projects that want to deploy to the web to use it for the performance / bloat wins.