... | ... | @@ -5,7 +5,7 @@ Here we are going to look at the compilation of a single module. |
|
|
There is a picture that goes with this description, which appears at the bottom of this page, but you'll probably find it easier to open [this link](commentary/compiler/hsc-pipe) in another window, so you can see it at the same time as reading the text.
|
|
|
|
|
|
|
|
|
You can also watch a **video** of Simon Peyton-Jones explaining the compilation pipeline here: [ Compiler Pipeline II](http://www.youtube.com/watch?v=Upm_kYMgI_c&list=PLBkRCigjPwyeCSD_DFxpd246YIF7_RDDI) (10'16")
|
|
|
You can also watch a **video** of Simon Peyton-Jones explaining the compilation pipeline here: [Compiler Pipeline II](http://www.youtube.com/watch?v=Upm_kYMgI_c&list=PLBkRCigjPwyeCSD_DFxpd246YIF7_RDDI) (10'16")
|
|
|
|
|
|
|
|
|
Look at the picture first. The yellow boxes are compiler passes, while the blue stuff on the left gives the data type that moves from one phase to the next. The entire pipeline for a single module is run by a module called HscMain ([compiler/main/HscMain.hs](/trac/ghc/browser/ghc/compiler/main/HscMain.hs)). Each data type's representation can be dumped for further inspection using a `-ddump-*` flag. (Consider also using `-ddump-to-file`: some of the dump outputs can be large!) Here are the steps it goes through:
|
... | ... | @@ -28,11 +28,11 @@ Look at the picture first. The yellow boxes are compiler passes, while the blue |
|
|
- error messages can display precisely the syntax that the user wrote; and
|
|
|
- desugaring is not required to preserve type-inference properties.
|
|
|
|
|
|
- The **SimplCore** pass ([compiler/simplCore/SimplCore.hs](/trac/ghc/browser/ghc/compiler/simplCore/SimplCore.hs)) is a bunch of Core-to-Core passes that optimise the program; see [ A transformation-based optimiser for Haskell (SCP'98)](http://research.microsoft.com/%7Esimonpj/Papers/comp-by-trans-scp.ps.gz) for a more-or-less accurate overview. See [Commentary/Compiler/Core2CorePipeline](commentary/compiler/core2-core-pipeline) for an overview of the Core-to-Core optimisation pipeline. The main passes are:
|
|
|
- The **SimplCore** pass ([compiler/simplCore/SimplCore.hs](/trac/ghc/browser/ghc/compiler/simplCore/SimplCore.hs)) is a bunch of Core-to-Core passes that optimise the program; see [A transformation-based optimiser for Haskell (SCP'98)](http://research.microsoft.com/%7Esimonpj/Papers/comp-by-trans-scp.ps.gz) for a more-or-less accurate overview. See [Commentary/Compiler/Core2CorePipeline](commentary/compiler/core2-core-pipeline) for an overview of the Core-to-Core optimisation pipeline. The main passes are:
|
|
|
|
|
|
- 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). (`-ddump-simpl`)
|
|
|
- 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. (Further described in [Demand analysis](commentary/compiler/demand).) The same analyser also does [ Constructed Product Result analysis](http://research.microsoft.com/%7Esimonpj/Papers/cpr/index.htm) and [ Cardinality analysis](http://research.microsoft.com/en-us/um/people/simonpj/papers/usage-types/cardinality-extended.pdf). (`-ddump-stranal`)
|
|
|
- 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). (`-ddump-simpl`)
|
|
|
- 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. (Further described in [Demand analysis](commentary/compiler/demand).) The same analyser also does [Constructed Product Result analysis](http://research.microsoft.com/%7Esimonpj/Papers/cpr/index.htm) and [Cardinality analysis](http://research.microsoft.com/en-us/um/people/simonpj/papers/usage-types/cardinality-extended.pdf). (`-ddump-stranal`)
|
|
|
- The **liberate-case** transformation.
|
|
|
- The **constructor-specialialisation** transformation.
|
|
|
- The **common sub-expression eliminiation** (CSE) transformation. (`-ddump-cse`)
|
... | ... | |