I was doing the "Implement a language with llvm" tutorial [1] last night. LLVM really is awesome... Why do we even make new languages for the JVM (apart from access to JVM libraries). LLVM seems so much more powerful as a basis.
I don't really know how long LLVM has been mature yet, so maybe it's not used because it's rather new. And of course it's way more low level than the JVM. It's probably easier to go JVM and not implement your own garbage collector.
Still, this could be the "portable platform" of the near future.
Well, libraries are probably the largest reason, as providing access to native libraries is much harder (if possible at all) on LLVM due to the lack of reflection in C or C++.
Aside from libraries, other reasons for it being unpopular include JIT compilation being slow for LLVM (compared to hand rolled implementations) lack of a mature GC infrastructure (for decent performance, iirc you are best off rolling your own with little/no help from LLVM) and general difficulties with the performance of compiled code for dynamic languages (many of its optimizations, e.g. LICM, TBAA, etc are unsuitable for dynamic languages. Other optimizations get tripped up by type guards, and cant do much useful work). Not to mention that LLVM is huge, and it can be a painful dependancy (especially given the above)
Another problem for LLVM as a portable platform is that LLVM bytecode is, well, not portable. I mean, how could it be? It must be able to encode the semantics of C, which is inherently non-portable (especially after e.g. sizeof has been replaced with machine dependant sizes).
That's not to say LLVM is not awsome, because it is--very much so. But LLVM's design goals have never included being a platform, as thats likely at odds with it being a great compiler for languages like C/C++. (Maybe not, but it certainly seems that way to me)
Edit: just realized you said apart from libraries. Rephrased some stuff to highlight other points
"LLVM’s intermediate representation provides garbage collection intrinsics that offer support for a broad class of collector models.
[...] We hope that the primitive support built into the LLVM IR is sufficient to support a broad class of garbage collected languages including Scheme, ML, Java, C#, Perl, Python, Lua, Ruby, other scripting languages, and more.
However, LLVM does not itself provide a garbage collector — this should be part of your language’s runtime library. LLVM provides a framework for compile time code generation plugins. The role of these plugins is to generate code and data structures which conforms to the binary interface specified by the runtime library. This is similar to the relationship between LLVM and DWARF debugging info, for example. The difference primarily lies in the lack of an established standard in the domain of garbage collection — thus the plugins.
[...]
On the plus side, this means that you should be able to integrate LLVM with an existing runtime. On the other hand, it leaves a lot of work for the developer of a novel language. However, it’s easy to get started quickly and scale up to a more sophisticated implementation as your compiler matures."
I don't really know how long LLVM has been mature yet, so maybe it's not used because it's rather new. And of course it's way more low level than the JVM. It's probably easier to go JVM and not implement your own garbage collector.
Still, this could be the "portable platform" of the near future.
[1] http://llvm.org/docs/tutorial/index.html#kaleidoscope-implem...