A very good point; I'm considering using LLVM for some projects, but I'm only interested in 32 and 64 bit x86 and ARM targets.
What big iron targets would you say are also required? Here are some possibilities I can think of: SPARC, IBM's z/Architecture (what about ESA/390 or earlier?) and POWER (the latter of which historically includes more than one ISA), Intel's IA-64 (Itanium, used by HP).
Which doesn't mean production level quality, of course.
More critically, just because LLVM has back end support of an architecture, doesn't mean any particular language using LLVM will support it, or at least as I recall, the language has to know and use details about the back ends it's targeting.
LLVM is currently not suitable for SPARC at all; it's existing SPARC backend was, to put it kindly, not written by someone intimately familiar with the architecture. There are problems on other architectures as well. ARM and x86 are really the best maintained (unsurprising).
Regardless, one of LLVM's biggest problems internally is the number of unaligned accesses, which hurts its performance on many architectures (except x86 of course, where the penalty is very minor). That's not specific to SPARC, but it does hurt performance there quite a bit as well as cause other problems.
What big iron targets would you say are also required? Here are some possibilities I can think of: SPARC, IBM's z/Architecture (what about ESA/390 or earlier?) and POWER (the latter of which historically includes more than one ISA), Intel's IA-64 (Itanium, used by HP).
Modulo the various Power ISAs, which I am not familiar with, LLVM claims "is generally reliable" support for all of the about except IA-64: http://llvm.org/docs/CodeGenerator.html#target-feature-matri...
Which doesn't mean production level quality, of course.
More critically, just because LLVM has back end support of an architecture, doesn't mean any particular language using LLVM will support it, or at least as I recall, the language has to know and use details about the back ends it's targeting.