The gccXllvm competition have been good for both parts, IMO.
[1]http://www.reddit.com/r/programming/comments/1nn6p3/libgccjitso_an_embeddable_jitcompiler_based_on_gcc/
http://dmalcolm.fedorapeople.org/gcc/global-state/
He's seriously invested in cleaning up gcc and making it a competitive compiler.
You should also see the API he has for JITing, it's much higher-level than LLVM:
https://github.com/davidmalcolm/jittest/blob/master/regvm.cc...
" This is his way to bring gcc into the modern era" and "He's seriously invested in cleaning up gcc and making it a competitive compiler."
Optimization wise, GCC is still much more modern than LLVM, and in fact, more modern than a most commercial compilers.
Architecture wise, there are warts, but bringing GCC into the modern era architecturally was never a technical/engineering challenge.
To be honest, speaking as a guy who wrote plenty of GCC's current optimizations, he'd be a lot better off fixing LLVM's JIT issues than trying to rearchitect GCC.
At this point, it's hard to come up with good reasons to continue work on GCC past "fun".
LLVM and gcc are optimized for producing the fastest possible code and will do so at the expense of spending more time doing it. That's not to say that they can't become great JIT compilers in the future, but I don't think we're there yet.
The Pypy developers (another Python with JIT project) looked very, very, carefully at every available JIT out there, and finally ended up writing their own. It was the only way that they could get something that would do what they needed. The results of doing that was performance that was far superior to what the Unladen Swallow project got when using LLVM.
It sounds very simple when you look at it from a distance. "We need a JIT, here's a JIT, let's use it." Then you find out that just because something is called a "JIT" doesn't mean that it will be of any use to what you are trying to do. The subject area is very complex and there will probably never be a universal solution.
What I could see the GCC JIT mode being useful for is things like generating certain critical portions of a program under programmer direction. That is, it would make a nice library that you call to generate very optimized code for specific functions or modules. A good example is how GCC is currently called in the background by a number of Python libraries which dynamically generate C code and compile it for faster execution. Being able to do this more directly via a JIT process could be very convenient. This is perhaps the sort of application that the author has in mind.
Current gcc is GPLv3 and that is very unlikely to change, if you link your project to this you are thoroughly "infected" by the GPL since unlike many GNU projects that are explicitly meant to be linked to by your own projects, gcc's core is not LGPL and the runtime library exemption granted by gcc is not sufficient to save you from infection in this use case.
If you are extending the compiler, why would you want to allow companies like apple and oracle to bottle up you hard work and not give anything back? Either by not giving the code back or by patenting parts of the functionality they add and then suing you when you try and use them.
One of the things in which Octave is much slower than Matlab is in looping. Matlab used to have this slowness too until they started JIT compiling their loops. For Octave, this has been more difficult, and the only tool that we've had for accomplishing this has been LLVM.
While our JIT compiler code is still very much alpha, it has already been quite a pain to deal with the LLVM JIT "API" because the truth is, they don't really have an API, i.e. no promise of stability. Every LLVM release has broken everything and our code keeps having to change in order to accomodate all of those changes. Every. Damn. LLVM. Release.
I don't know how stable the JIT API for gcc will be, but already it's starting to look much better and thought-out as a public API. Here's hoping that our fellow GNUs-in-arms can help us make a faster and better Octave!
