Which version of LLVM IR are we talking about here? Since LLVM's IR is intended to be used as a compiler IR and not an executable bytecode format, it changes in backwards-incompatible ways on a regular basis. Google's PNaCL solves this by snapshotting a particular version of LLVM and using a subset of the IR of that version of LLVM. Last I heard, if they ever needed to support newer versions of LLVM the plan was to create a completely new, incompatible version of the PNaCL bitcode from it.
Yes, LLVM is forwards compatible, not backwards compatible.
While you are wrong, because it is in fact " an executable bytecode format", it does change in backwards-incompatible ways.
However, it has not done so "on a regular basis" (to say otherwise is complete bullshit. I'm pretty sure the last major backwards incompatible change was version 3.0, which was 2 years ago). However, from where I sit, it's changed seriously less than asm.js in the past few years!
We'll see how long asm.js actually stays backwards compatible without having real impact.
How would asm.js break backwards compatibility? It has to be executable javascript; it can't change execution semantics without changing JS execution semantics. It is the case that support for a wider set of features could be added, and that stuff wouldn't get AOT-compiled in older browsers, but nothing would break. It'd just be slower.
'seriously less than asm.js in the past few years' is a blatantly fallacious claim. asm.js, as a spec, is barely a year old (going by the date of dherman's first public commit to his github repository) and the first implementation is younger than that. Mozilla turned the implementation around in a few months with a handful of engineers.
"Most of the changes needed to fill in the few remaining holes in asm.js help everyone. SIMD and 64-bit integers, for example, are something the entire Web would benefit from, asm and non-asm writers alike."
Such changes would almost certainly be backwards incompatible with what exists now.
"'seriously less than asm.js in the past few years' is a blatantly fallacious claim."
Errr, given asm.js has changed a lot in the year it's been around, and LLVM has not changed in any backwards compatible way in that time period, it's actually what you would call "trivially true", not "blatantly false".
New features like SIMD and 64-bit integers would not be asm.js features, they would be JavaScript features. If you read his comments more carefully you would realize this, since he mentions how they're being developed as JavaScript features...
Again, asm.js has 'changed' but has not broken backwards compatibility, because it's just javascript and remains so.
This is a word game.
You can't define away the problem of backwards compatibility by saying "well it wasn't us who changed in a backwards incompatible way, it was the underlying language we subset".
You especially can't do this when the parent made the claim that PNaCL has exactly this issue.
