"LLVM IR was also never designed to be a portable, platform-independent, well-specified bytecode."
This is completely and utterly false in every way. This is exactly what it was meant to be, and is. Maybe you mean "it does not turn non-portable languages, like C, into portable ones".
This does not change whether it is a portable, platform independent, well-specified bytecode. This is even covered in the FAQ.
To your specific examples
TargetData is meant to deal with languages that have unavoidable target specific dependencies, like C. It is unnecessary in portable languages.
Download size is completely unrelated to a portable, platform-independent, well-specified bytecode, and is probably the absolutely most trivial thing to fix in the world if it was necessary. I'm not sure why one would even bring this up.
Undefined behavior is not necessarily bad. Most languages specify some amount of undefined behavior. This is done on purpose, to enable certain classes of optimizations.
Is your claim that asm.js has no undefined behavior?
emscripten certainly does, even in asm.js mode.
My guess is that you meant that asm.js has a bunch of properties that are statically verifiable, and it validates conformance at compile time. That is great, but not really the same as "no undefined behavior". At a glance, asm.js has undefined behavior. For example: "As JavaScript functions, they produce the undefined value, but asm.js code is not allowed to make use of this value"
A program that attempted to make use of it would exhibit undefined behavior. It would be noncomforming to the asm.js spec, in the same way that a program in LLVM IR that uses undefined behavior is noncomforming to the language specification. Again, you may mean that you statically verify this, which is great, but that does not mean the spec does not deal have undefined behavior. It just means you try to validate conformance at compile time (and note, the asm.js spec itself explains why it can't possibly accomplish no actual undefined behavior at runtime: ' In particular, reading out of bounds from a typed array produces undefined, and calling FFI functions may produce arbitrary JavaScript values.')
"I certainly don't think there will be any fundamental limitations 5 years from now."
If you didn't believe this, i'm sure y'all wouldn't be working on asm.js. :)
However, I strongly disagree.
What you are doing is not the first time someone has tried to do something like this (see, e.g., the SIMPLE IR and other IR's the McCat compiler used to use), and it won't be the last. Your claim essentially comes down to "this time for sure!". Sorry, but living in the world of compilers, i've seen and heard this too many times.
The truth is there are no magic bullets in compiler technology, and asm.js isn't one either. It's a set of tradeoffs. I don't believe this chosen set of tradeoffs come without fundamental limitations.
I guess we'll see whether you are right.
"> Not to mention, LLVM, and it's IR, certainly has more traction than "asm.js".
Not on the Web, which is the important thing here."
You can always define a target audience that likes your stuff more. So let's go this way: Researchers, compiler developers, and a very large contingent of companies care very strongly about LLVM and improving it.
I certainly wouldn't disagree with "worse is better" often wins, particularly on the web.
Posts like yours demonstrate that you're arguing fervently about asm.js without having used it. One obvious error:
My guess is that you meant that asm.js has a bunch of properties that are statically verifiable, and it validates conformance at compile time. That is great, but not really the same as "no undefined behavior". At a glance, asm.js has undefined behavior. For example: "As JavaScript functions, they produce the undefined value, but asm.js code is not allowed to make use of this value"
'Not allowed to make use of this value' means that the asm.js application will not get AOT compiled if it tries to use the value, because it's not a valid asm.js application. So the behavior isn't 'undefined', it doesn't work. The AOT compiler rejects it and it runs as regular JS, in which case the behavior is 'defined' in that it works the way all other regular JS does.
asm.js is specced and there's a verifier; if you pass the verifier your code should behave predictably in an AOT-compiling runtime. The runtime isn't producing code that does dynamic type checks at runtime or other sorts of nondeterministic behavior.
It's certainly possible that some undefined behavior slipped into the spec somewhere, but I definitely haven't seen any actual examples where they specced it and the Firefox implementation generates undefined behavior on purpose. That would be insane. asm.js delivers the same safety guarantees as regular JS; you can't do that with undefined behavior ala C.
Ultimately if you have concerns about the safety of asm.js or the presence of undefined behavior, you should test it and report bugs. I've tested asm.js some and played around with it and have not found any reason to be concerned.
"Posts like yours demonstrate that you're arguing fervently about asm.js without having used it. One obvious error:
"
Sorry, but no. Also, I was addressing points made about LLVM IR, and the asm.js specification, as well as it's suitability as a compiler IR. I've used asm.js, i've read and understood the current optimizing compiler implementation, as well as the published roadmaps and mailing lists.
I don't appreciate the unrelated attack, it was completely unwarranted and unnecessary. The fact that I don't agree with you does not mean "I haven't used it".
" So the behavior isn't 'undefined', it doesn't work."
You completely misunderstand undefined behavior.
The behavior is undefined, it is simply verified at compile time that the program does not perform it. That does not make it less undefined, it makes the program "statically checked" as opposed to "dynamically checked" or "not checked at all" (like most C, though it's worth pointing out it's entirely legal for a C compiler to reject code producing undefined behavior, it's only required to accept implementation defined behavior).
Exactly as I said, C programs (or others) that exhibit undefined behavior are in fact noncomforming, in exactly the same way that the asm.js program would be noncomforming. The only difference is when and whether checking and rejection of nonconforming behavior is performed.
If you are going to argue about language specifications, and make claims about them, you need to be precise.
pcwalton likely meant to make the claim that asm.js itself is safer because it has no undefined behavior at runtime, as it rejects programs that may exhibit undefined behavior at compile time (or something similar), which is at least possible to be true, though i would have a lot of trouble believing it without some formal proof (the spec offers none). It is incredibly hard to actually come up with things like this that are completely statically decidable and still useful.
Your definition of behavior that does not meet the spec as "defined" because "it works the way it all regular JS normally does" is a hilarious new definition of 'defined behavior'.
Also, would you like to refute any other point I have made about how pcwalton has completely misrepresented a lot about LLVM IR?