4 ms·

There is a long tradition of type-directed compilation. Haskell compilation system refers to it as the simplifier or "middle end". The parsing and type-checki

There is a long tradition of type-directed compilation. Haskell compilation system refers to it as the simplifier or "middle end". The parsing and type-checking produces a IR known as 'Core'. The middle-end optimizes it as a series of source-to-source transformations on Core code. The back end of the compiler transforms Core code into an internal representation of a C dialect called C--, via yet another intermediate language STG (short for "Spineless Tagless G-machine"). Finally, the C-- code output can either be printed as C code for compilation with GCC, converted directly into native binary, or converted to LLVM virtual machine code for compilation with LLVM. Any output is linked against the Haskell runtime. The innovation would come in creating the optimizations in the middle-end that could not be possible in the LLVM backend. Proof is in the pudding. Introducing another layer without any meaningful results is how projects bloat (NIH syndrome). There is a LLVM backend that implements most if not all of the GHC "middle-end" optimizations[0] and should provide you with details/context you are seeking. [0] http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-llvm.html http://blog.llvm.org/2010/05/glasgow-haskell-compiler-and-ll...

Tehnix 10y ago
>The innovation would come in creating the optimizations in the middle-end that could not be possible in the LLVM backend >There is a LLVM backend that implements most if not all of the GHC "middle-end" optimizations I'm not sure I follow, are you saying that the optimisations are possible or not in LLVM? I don't think the LLVM optimisation passes can make guarantees such as is needed for (say) the rewrite rules that rely heavily on purity.
- shawn-butler 10y ago
  Please read the link I provided and search the page for "Problems with the backend" ...There is one major issue remaining with the LLVM backend that I currently know of, its inability to implement a optimisation used by GHC called 'TABLES_NEXT_TO_CODE' (TNTC)...
  - aseipp 10y ago
    That was fixed in LLVM 3.6 in a more general way, by one of my coworkers, Ben. http://reviews.llvm.org/D6454 http://reviews.llvm.org/D6454 The prologue support directly subsumes previous behavior (the `prefix` form) and is more flexible, and with it, GHC doesn't have to rely on shuffling assembly output in order to achieve TNTC.
- aseipp 10y ago
  LLVM doesn't ever even bother with rewrite rules. That's done substantially earlier in the compiler, at the Core phase (rewrite rules are 'just' equational reasoning optimizations that the compiler is aware of, so it works roughly at the level of the program you write, vs any more complicated intermediate form.) There is still some inlining/smarts going on at the LLVM level, obviously, but it's nowhere near as aggressive as it is at the Core level in GHC. And obviously rewrite rules are user-definable - so they kick in much earlier. (As a side note, we actually spit out pretty optimized LLVM code from the C-- backend, in such a way that only some of LLVM's heaviest optimizations make a difference). There are some specific optimizations that are simply not possible for LLVM in the general case and are better handled before conversion (for example, C-- at one point essentially gets CPS transformed in a way which LLVM cannot 'see through', and by that point you've lost the opportunity to do a number of simpler optimizations like basic constant propagation, while it's trivial to do earlier). But that's mostly the same in any compiler, and not unique to GHC...

Tehnix 10y ago

>The innovation would come in creating the optimizations in the middle-end that could not be possible in the LLVM backend >There is a LLVM backend that implements most if not all of the GHC "middle-end" optimizations I'm not sure I follow, are you saying that the optimisations are possible or not in LLVM? I don't think the LLVM optimisation passes can make guarantees such as is needed for (say) the rewrite rules that rely heavily on purity.

shawn-butler 10y ago
Please read the link I provided and search the page for "Problems with the backend" ...There is one major issue remaining with the LLVM backend that I currently know of, its inability to implement a optimisation used by GHC called 'TABLES_NEXT_TO_CODE' (TNTC)...
- aseipp 10y ago
  That was fixed in LLVM 3.6 in a more general way, by one of my coworkers, Ben. http://reviews.llvm.org/D6454 http://reviews.llvm.org/D6454 The prologue support directly subsumes previous behavior (the `prefix` form) and is more flexible, and with it, GHC doesn't have to rely on shuffling assembly output in order to achieve TNTC.
aseipp 10y ago
LLVM doesn't ever even bother with rewrite rules. That's done substantially earlier in the compiler, at the Core phase (rewrite rules are 'just' equational reasoning optimizations that the compiler is aware of, so it works roughly at the level of the program you write, vs any more complicated intermediate form.) There is still some inlining/smarts going on at the LLVM level, obviously, but it's nowhere near as aggressive as it is at the Core level in GHC. And obviously rewrite rules are user-definable - so they kick in much earlier. (As a side note, we actually spit out pretty optimized LLVM code from the C-- backend, in such a way that only some of LLVM's heaviest optimizations make a difference). There are some specific optimizations that are simply not possible for LLVM in the general case and are better handled before conversion (for example, C-- at one point essentially gets CPS transformed in a way which LLVM cannot 'see through', and by that point you've lost the opportunity to do a number of simpler optimizations like basic constant propagation, while it's trivial to do earlier). But that's mostly the same in any compiler, and not unique to GHC...