No, the primary optimization asm.js brings (at least in OdinMonkey) is AOT compilation.
But it can do that precisely because of the static typing, which loops back to exactly what I said. Looser, more dynamic language always have a cost associated with that flexibility.
Arbitrary JS can be as statically typed as asm.js is (because, well, asm.js is just a subset). There's no reason why one couldn't compile AOT something like:
function add_and_double(a, b) {
a = a | 0;
b = b | 0;
var sum = (a + b) | 0;
return (sum + sum) | 0;
}
Yes, it'd be trivial to fall off the AOT-compilation path (esp. without a defined subset that got AOT compilation and hence likely would differ between implementations), so static verification that you're on the AOT-compilation path is valuable (which asm.js provides), but it doesn't fundamentally alter the semantics of the language.
You seem to be saying that the AOT path requires constrained typing and a strict subset of the language semantics, which agrees with the parent's point that static type semantics matter in terms of performance.
But it is extremely specific to asm.js -- the optimizations possible can only happen because static typing is mandated. It is absolutely a subset of JS, but JS can't make those optimizations because the guarantees aren't there.
But it can do that precisely because of the static typing, which loops back to exactly what I said. Looser, more dynamic language always have a cost associated with that flexibility.