... | ... | @@ -32,7 +32,7 @@ Look at the picture first. The yellow boxes are compiler passes, while the blue |
|
|
|
|
|
- The **Simplifier**, which applies lots of small, local optimisations to the program. The simplifier is big and complicated, because it implements a *lot* of transformations; and tries to make them cascade nicely. The transformation-based optimiser paper gives lots of details, but two other papers are particularly relevant: [ Secrets of the Glasgow Haskell Compiler inliner (JFP'02)](http://research.microsoft.com/%7Esimonpj/Papers/inlining/index.htm) and [ Playing by the rules: rewriting as a practical optimisation technique in GHC (Haskell workshop 2001)](http://research.microsoft.com/%7Esimonpj/Papers/rules.htm).
|
|
|
- The **float-out** and **float-in** transformations, which move let-bindings outwards and inwards respectively. See [ Let-floating: moving bindings to give faster programs (ICFP '96)](http://research.microsoft.com/%7Esimonpj/papers/float.ps.gz).
|
|
|
- The **strictness analyser**. This actually comprises two passes: the **analyser** itself and the **worker/wrapper** transformation that uses the results of the analysis to transform the program. The same analyser also does [ Constructed Product Result analysis](http://research.microsoft.com/%7Esimonpj/Papers/cpr/index.htm).
|
|
|
- The **strictness analyser**. This actually comprises two passes: the **analyser** itself and the **worker/wrapper** transformation that uses the results of the analysis to transform the program. (Further described in [Demand analysis](commentary/compiler/strictness-analysis).) The same analyser also does [ Constructed Product Result analysis](http://research.microsoft.com/%7Esimonpj/Papers/cpr/index.htm).
|
|
|
- The **liberate-case** transformation.
|
|
|
- The **constructor-specialialisation** transformation.
|
|
|
- The **common sub-expression eliminiation** (CSE) transformation.
|
... | ... | |