| 134 | | * Ben Lippmeir spent his internship building a graph-colouring, |
| 135 | | coalescing register allocator for GHC's native code generator. |
| 136 | | SIMON SAY MORE |
| | 134 | GHC's back end code generator has long been known to generate poor code, particularly |
| | 135 | for tight loops of the kind that are cropping up more and more in highly optimised |
| | 136 | Haskell code. So in typical GHC style, rather than patch the immediate problem, we're redesigning |
| | 137 | the entire back end. |
| | 138 | |
| | 139 | What we want to do: |
| | 140 | |
| | 141 | * split the STG-to-C-- code generator (`codeGen`) into two: one pass |
| | 142 | generating C-- with functions and calls, and a second pass ("CPS") to |
| | 143 | manifest the stack and calling/return conventions. |
| | 144 | |
| | 145 | * Redesign the calling and return conventions, so that we can use more |
| | 146 | registers for parameter passing (this will entail decommissioning the |
| | 147 | via-C code generator, but the native code generator will outperform it). |
| | 148 | |
| | 149 | * Give the back end more opportunity to do low-level transformation and |
| | 150 | optimisation, e.g. by exposing loops at the C-- level. |
| | 151 | |
| | 152 | * Implement more optimisations over C--. |
| | 153 | |
| | 154 | * Plug in a better register allocator. |
| | 155 | |
| | 156 | What we've done so far: |