3 ms·

>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 impleme

by 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...

by Tehnix 10y ago

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...