Version 52 (modified by simonpj, 3 years ago) (diff)


Compiling one module: HscMain


You can also watch a video of Simon Peyton-Jones explaining the compilation pipeline here: Compiler Pipeline II (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). 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:

  • The Front End processes the program in the big HsSyn type. HsSyn is parameterised over the types of the term variables it contains. The first three passes (the front end) of the compiler work like this:

    • The Parser produces HsSyn parameterised by RdrName. To a first approximation, a RdrName is just a string. (-ddump-parsed)




  • The Desugarer (compiler/deSugar/Desugar.lhs) converts from the massive HsSyn type to GHC's intermediate language, CoreSyn. This Core-language data type is unusually tiny: just eight constructors.) (-ddump-ds)


    This late desugaring is somewhat unusual. It is much more common to desugar the program before typechecking, or renaming, because that presents the renamer and typechecker with a much smaller language to deal with. However, GHC's organisation means that
    • desugaring is not required to preserve type-inference properties.


It makes a difference whether or not you are using -O at this stage. With -O (or rather, with -fomit-interface-pragmas which is a consequence of -O), the tidied program (produced by tidyProgram) has unfoldings for Ids, and RULES. Without -O the unfoldings and RULES are omitted from the tidied program. And that, in turn, affects the interface file generated subsequently.



    • The second step, CoreToStg, moves to the StgSyn data type (compiler/stgSyn/CoreToStg.lhs). The output of CorePrep is carefully arranged to exactly match what StgSyn allows (notably ANF), so there is very little work to do. However, StgSyn is decorated with lots of redundant information (free variables, let-no-escape indicators), which is generated on-the-fly by CoreToStg.
  • Now the path forks again:
    • If we are generating native code, we invoke the native code generator. This is another Big Mother (compiler/nativeGen).
    • If we are generating LLVM code, we invoke the LLVM code generator. This is a reasonably simple code generator (compiler/llvmGen).

The Diagram


Attachments (2)

Download all attachments as: .zip