I don't see any disagreement along those lines in the thread under discussion here. The LLVM project is quite clear (it says so on its homepage!) that it is not making a typical virtual machine along the lines of the JVM. What are you talking about? This sounds like completely random and out-of-context FUD.
And yet it says it might be used to build such, and this thread contains disagreement amongst the developers of the original purposes and the meaning of "virtual machine".
I'm just a developer who has looked into LLVM in the recent past for possible use in cross-platform projects and come away more confused than enlightened, and this thread just magnified it. Interpreting that as "FUD" is wildly unhelpful.
You are really making this out to be more confusing than it is. If you're not doing that intentionally, I think you should take a step back and try to look at things again without the assumption "This is confusing and everybody disagrees with each other."
Yes, the LLVM site does say it can be used in the construction of a virtual machine. That's factual. It has been used to construct actual, shipping virtual machines (e.g. Apple's MacRuby project). But that is not its primary or only use, and I don't think anyone would make that assumption if not for the name.
As for that thread, it contains some discussion among the developers about what LLVM is good for, but actually, nobody's really disagreeing with anybody else about what LLVM is and what it's good for.
Dan Gohman starts it out claiming that LLVM IR is not a very good bytecode for a portable virtual machine, and that if you want to build a portable VM, you'll need a separate layer for your bytecode.
Chris Lattner's reply (which you seem to read as disagrement) is essentially, "Yes, you're right, but here are the upsides that we get in exchange for those weaknesses as a bytecode."
In a sense. I was after a bytecode that had a JIT for the more common platforms (e.g. x86, ARM, possibly MIPS), could be extended for new ones without massive effort (even if sub-optimally), and had reasonable facilities for hooking into native code, and I was trying to avoid the complex baggage, legacy or otherwise, of a JVM.
LLVM initially looked like a candidate, but I walked away with conflicting ideas about whether it was even intended to be suitable for such a case, much less whether it actually was.
Think of LLVM as a back end for compiling C with exception support and a few more bits and pieces (e.g. GC hooks). Treat LLVM bitcode as a platform-specific artifact; i.e. don't try to share the same bitcode across multiple CPU targets and OS platforms, no more than you'd try to share the same C code across the same without using any conditional compilation symbols (i.e. it would be close to impossible).
LLVM bitcode isn't a good intermediate format for platform independence, for transport or for interpretation. What it is good for is having separate compilation while delaying whole program optimization until "link time" (but is actually LLVM linking time, not actual object file linking). LLVM bitcode lets you have multiple bits and pieces of a program written in different languages yet still have whole program optimization (e.g. inlining) across language boundaries. Look at it like that.
If you're trying to create a JIT for multiple platforms, I'd start with a bytecode format that is either easy to interpret or easy to transform trivially into naive CPU instructions (the former is better for high-level optimizations because it will retain high-level semantics, the latter a better shortcut for speed by skipping interpretation); treat LLVM as a CPU target, but be aware you'll probably want to generate different LLVM instructions for minor differences between final target platforms that poke through the abstraction layer. You'll need to either invent that bytecode format yourself or reusing someone else's (depending on what language you're trying to execute, I expect); but I wouldn't look to LLVM to give you that bytecode.
