Not significantly. If you check out the sources for most functional language compilers (GHC, any of the ML family, scheme, etc.), code generation and micro-optimizations make up a tiny fraction of the code and developer time investment. LLVM is a fabulous project, but many of the optimizations that it performs are already handled at a higher level of the compiler (loop unrolling, inlining, etc.) in a type-preserving functional language. Richer type information (particularly for algebraic datatypes) enables things like loop unrolling over recursive data structures, which you really can't do anymore once it's a bunch of typecasts and tagged union discriminations.
That said, we're looking to move over to it because our old code generation library (MLRISC) is beginning to show its age, and porting to LLVM is probably going to be about as much work as fixing the spill code bug we recently hit and exposing more SSE instructions. Most of the work will probably be in porting our calling convention, which does not resemble C's in any way. Like many frameworks, it's a modular compiler framework for building C compilers, not really a modular compiler framework for all types of compilers.
That's not necessarily a bad thing; many people have tried and failed to make more general ones. I'd rather have to do work to shoehorn our compiler into something that works and is widely used in industry than rely on something that's an easier fit but only likely to be around as long as the group is still publishing papers on it.
> Most of the work will probably be in porting our calling convention, which does not resemble C's in any way. Like many frameworks, it's a modular compiler framework for building C compilers, not really a modular compiler framework for all types of compilers.
GHC folks succeeded in including GHC calling convention in LLVM, so there is hope.
Yes, we're familiar with that work. One technical bit of interest is that we don't use the C stack at all (we have heap-allocated continuation records), so we're curious how that will play out with the calling convention even beyond the issue with registers.
That said, we're still hopeful that we can make things work, though we're not optimistic that it will come about without some significant tweaking.
That said, we're looking to move over to it because our old code generation library (MLRISC) is beginning to show its age, and porting to LLVM is probably going to be about as much work as fixing the spill code bug we recently hit and exposing more SSE instructions. Most of the work will probably be in porting our calling convention, which does not resemble C's in any way. Like many frameworks, it's a modular compiler framework for building C compilers, not really a modular compiler framework for all types of compilers.
That's not necessarily a bad thing; many people have tried and failed to make more general ones. I'd rather have to do work to shoehorn our compiler into something that works and is widely used in industry than rely on something that's an easier fit but only likely to be around as long as the group is still publishing papers on it.