I've recently browsed some assembly code generated by GHC (via gcc). It appeared that most values were accessed via memory, because the stack is managed by GHC explicity. Even intermediate results seem accessed via memory, probably due to shortcomings of aliasing analysis in gcc. (?)

This brings on the topic of eval/apply vs push/enter. In the eval/apply model, the stack management can (possibly) be left to an underlying compiler, which would remove most memory accesses, and leave most of the alignment issue to the back-end. (http://research.microsoft.com/Users/simonpj/papers/eval-apply/)

From that article, I can only assume that GHC will switch to the eval/apply model. Can we expect that soon? The "alignment" thing would become easier to deal with...

We've already made the switch to eval/apply for the next release of GHC. However, deferring the entirety of stack management to an underlying compiler is not that easy: we do accurate garbage collection, so we need to retain enough information about the compiler's idea of stack layout in order to be able to find all the pointers during GC. We therefore can't compile via C using an ordinary C compiler and leave the stack management up to the C compiler. C-- has a solution to this problem, but there is neither a C-- compiler or a C-- back end for GHC (yet). Cheers, Simon