Linked by Thom Holwerda on Sat 29th Sep 2007 21:26 UTC, submitted by Chris Lattner
General Development The LLVM Project recently released a new version of their compiler, optimizer and code generators. LLVM includes a drop-in GCC-compatible C/C++ and ObjC compiler, mature optimization technology (including cross file/whole program optimization), and a highly optimizing code generator. For people who enjoy hacking on compilers and runtimes, LLVM provides libraries for implementing custom optimizers and code generators including JIT compiler support. This release is the first to provide beta GCC 4.2 compatibility as well as the new "clang" C/ObjC front-end, which provides capabilities to build source-to-source translators and many other tools.
Thread beginning with comment 275485
To view parent comment, click here.
To read all comments associated with this story, please click here.
lupus
Member since:
2006-01-30

I don't know about other projects (I guess if a new project was started right now that needed an execution engine, they should consider llvm), but I can tell you why Mono doesn't use llvm.

First when Mono started writing its own JIT llvm was very immature (we're talking about 6 years ago): it is now mature as a compiler, but still very much unproven as a JIT.

Second, Mono supports more architectures than llvm and has done so for several years, so unless llvm catches on, we're not going to lose supported architectures.

Third, llvm is HUGE: just the x86 specific code (in an optimized build) is as large as the whole Mono runtime (which includes 500 KB of locale data). This makes it unsuitable for the environments where Mono is already used, like embedded devices. The bloat factor translates also to runtime memory usage and JIT compilation speed. While llvm is definitely faster than gcc, that doesn't say anything when you need to JIT code as fast as possible (and when you need to load 2 MB of code in the cache just to jit a single method it starts to drag everything down, not including the data structures needed by the JIT process itself).

Then there are various other reasons, like the tight control the Mono runtime needs on some generated code (the llvm exception handling mechanisms are inadequate for a full featured runtime like Mono), the integration with the GC (llvm has some embryonal support for this),
the need to control runtime behaviour precisely vs memory and stack usage (the amount of stack space the JIT can use is small and it needs to be deterministically fixed: using llvm here would need having a black box with not control on it), some low level details that I explained some time ago in a posting to lamba the ultimate that you might want to check.

Overall, for Mono to switch to llvm, a lot of work would be needed: implementing all the missing features in llvm, de-bloating it, writing the ports for the missing architectures and finally writing the backend to target llvm inside Mono. This is easily 2 years of work just to get something working correctly (and some things would be still suboptimal, it's hard to debloat the x86 support code from 1.5MB as it is in llvm to the 100KB it is in Mono). In the same amount of time we can add more architectures to the supported list or write more optimizations that are suitable for a JIT compiler.

Reply Parent Score: 4