Optimize emscripten targets with emcc

[brson]

With today's asmjs and wasm targets, we optimize the LLVM IR ourselves, and pass that IR to emcc. emcc has its own optimization options though, including but not limited to LLVM's optimization passes, so we should probably leave all optimizations to emcc. Likewise LTO should be delegated to emscripten.

So we need to change the backend to treat these targets as unoptimized in LLVM, and instead pass the optimization arguments to emcc during the "link" step. This may involve adding new features to the target spec, or possibly just special casing emscripten in the backend.

[brson]

Some optimization levels in emcc seem to disable exception handling, so we might need to be careful about exactly what we're telling emcc to do.

[Thinkofname]

-s DISABLE_EXCEPTION_CATCHING=0 can be used to re-enable that although i'm not sure if we need that? I haven't seen a case where it comes up when i've been playing around.

[brson]

Actually we do need to continue optimizing our IR. emcc won't do it for us.

[DemiMarie]

@Thinkofname Emscripten's current handling of exceptions is horrendous: it injects a try/catch block into almost every function. V8's optimizing compiler bails out on try/catch and other JS engines don't do well either.

So you basically need to disable LLVM-level exception handling if you want good performance on emscripten.

Fortunately, I believe (not tested!) that a workaround exists: lower panic to a call to a helper function (written in ordinary JS) that throws an exception, and lower recover to a helper function (again handwritten in ordinary JS) taking a callback.

This is really an Emscripten bug. Perhaps someone could write a patch?