Don't take it too far. For purposes it was designed to serve, LLVM is great, best in its class. If your project is something that could benefit from LLVM, then by all means use it. If it isn't, then don't. As simple as that.

Many corporations (most of all Apple) bet millions of $$$s in resources on projects that depend on LLVM, so don't worry too much.

And what purpose was it designed to serve? That's exactly the problem I'm alluding to -- the LLVM developers don't even agree amongst themselves, so how am I supposed to know?

It's a compiler-building framework and toolchain.

LLVM is a square peg. If your project needs a square shaped peg then it will do amazing things for you. On the other hand if you want it to do circle shaped things you will feel the pain.

Thanks for the fortune-cookie wisdom. That tells no one anything. We don't have square pegs or round holes, we have complex engineering problems to solve, and LLVM's complex shape is obscured by a community that doesn't agree on its shape, so we have no way to tell if it fits our holes.

So you shoot down his "fortune-cookie wisdom", and correct him with the same type of analogy. Was the bile necessary?

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."

Are you trying to make a compiler that targets multiple platforms?

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.

I believe LuaJIT can compile Lua bytecode as well as source code. The latest LuaJIT works on ARM (without requiring an FPU), x86, and x64.