Thanks for all the details! We're looking at moving from MLRISC to LLVM in Manticore, and some knowledge of the pitfalls in the terrain are definitely helpful. We're most worried about our ridiculously custom calling convention while in-ML, but the optimization limitations are good to hear about.
For your point #3 ("Haskell itself"), do you do any block coalescing? In Manticore, once we're in our final IR before codegen (basically a first-order CPS language), we have a few tricks to help our code generator out from this:
1) If f only calls g and g is only called by f, merge the two blocks. During the merge, add the gc check for g to the top of the entire block. This optimization is extremely effective, but only because of our control-flow analysis results, since so many of our jumps are indirect.
2) Don't split blocks or do multiple GC checks in a block where one will do. So, if you allocate multiple small tuples, do a single GC check for all the space you will need in the block.
I'm sure John probably mentioned these to the Simons, but just in case...
For your point #3 ("Haskell itself"), do you do any block coalescing? In Manticore, once we're in our final IR before codegen (basically a first-order CPS language), we have a few tricks to help our code generator out from this:
1) If f only calls g and g is only called by f, merge the two blocks. During the merge, add the gc check for g to the top of the entire block. This optimization is extremely effective, but only because of our control-flow analysis results, since so many of our jumps are indirect.
2) Don't split blocks or do multiple GC checks in a block where one will do. So, if you allocate multiple small tuples, do a single GC check for all the space you will need in the block.
I'm sure John probably mentioned these to the Simons, but just in case...