Worst case, I expect individual compilers will develop their own bytecode serialization format that generates asm.js on the client. There are various reasons to do it already (compression, debug vs release readability/minification concerns, etc) and future revisions of asm.js (like v2, which introduces Java/C#-oriented heap structures) will make it worthwhile.
Compiler -> Bytecode -> Normal JS/ASM.js is the long term strategy for asm support in JSIL, since it will depend on currently-experimental asm features and using asm+polyfills on all browsers would have obscenely bad performance characteristics.
Comments
Worst case, I expect individual compilers will develop their own bytecode serialization format that generates asm.js on the client. There are various reasons to do it already (compression, debug vs release readability/minification concerns, etc) and future revisions of asm.js (like v2, which introduces Java/C#-oriented heap structures) will make it worthwhile.
Compiler -> Bytecode -> Normal JS/ASM.js is the long term strategy for asm support in JSIL, since it will depend on currently-experimental asm features and using asm+polyfills on all browsers would have obscenely bad performance characteristics.