One of my concerns with LLVM is its appetite for "elegance" means it risks biting off more than it can comfortably chew. A wonderfully general and composable framework is all well and good, but as a practical matter, there are more direct routes when what you want is to arrive at a destination.<p>I work on the Delphi compiler. In Delphi 2 (released in 1996), the compiler, in 65K lines of C source, implemented not just the usual lexer, parser, OO type system, optimizer, code generator etc., but also a build system (conventionally the main .dpr specified all units used by project), an object file reader and writer, a unit file reader and writer (a richer object file with full symbol table info), a smart linker and a resource linker. It could do that in part because it only targeted x86 on Windows, but also because it had a goal of simplicity of use in mind: all you needed was the compiler executable and a path to the RTL units, and you could compile anything you needed without fuss. Not wholly relying on 70s era assembler and linker technology meant that e.g. bad links with mismatched import and export symbol types could be eliminated.<p>LLVM earlier had a goal of being able to skip the assembler step and produce object files directly. But it appears that since that didn't work out too well, now LLVM is reimplementing a general assembler framework entirely. The risk is that they are expanding the project's focus so much that in its breadth, it gets stretched a little thin so that scenarios not tested by the mainline path of Clang on Mac / Linux atrophy. As it is, support for precise GC doesn't seem wonderful, and there's no support for Win32 SEH, etc. Support for interesting stack models (think e.g. Erlang, stackless python) seems to extend little more than tail call support.<p>That said, it's great that LLVM exists, and can act as a hub for commercial investment in open source back end compiler technology. I'm currently playing with LLVM as a back end for a toy project right now.