Changes between Version 10 and Version 11 of Commentary/Compiler/HscMain


Ignore:
Timestamp:
Sep 11, 2006 12:46:49 PM (8 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/HscMain

    v10 v11  
    1 [ Up: [wiki:Commentary] ] 
     1 
    22 
    33= Compiling one module: !HscMain = 
     
    1010 * The program is initially parsed into the [wiki:Commentary/Compiler/HsSynType big HsSyn type]. 
    1111 
    12  * {{{HsSyn}}} is parameterised over the types of the variables it contains.  The first three passes (the front end) of the compiler work like this:[[BR]][[BR]] 
     12 * {{{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:[[BR]][[BR]] 
    1313   * The '''parser''' produces {{{HsSyn}}} parameterised by '''[wiki:Commentary/Compiler/RdrNameType RdrName]'''.  To a first approximation, a {{{RdrName}}} is just a string.[[BR]][[BR]] 
    1414   * The '''[wiki:Commentary/Compiler/Renamer renamer]''' transforms this to {{{HsSyn}}} parameterised by '''[wiki:Commentary/Compiler/NameType Name]'''.  To a first appoximation, a {{{Name}}} is a string plus a {{{Unique}}} (number) that uniquely identifies it.[[BR]][[BR]] 
    1515   * The '''typechecker''' transforms this further, to {{{HsSyn}}} parameterised by '''[wiki:Commentary/Compiler/EntityTypes Id]'''.  To a first approximation, an {{{Id}}} is a {{{Name}}} plus a type. In addition, the type-checker converts class declarations to {{{Class}}}es, and type declarations to {{{TyCon}}}s and {{{DataCon}}}s.  And of course, the type-checker deals in {{{Type}}}s and {{{TyVar}}}s. The [wiki:Commentary/Compiler/EntityTypes data types for these entities] ({{{Type}}}, {{{TyCon}}}, {{{Class}}}, {{{Id}}}, {{{TyVar}}}) are pervasive throughout the rest of the compiler. 
    1616 
    17  * The '''desugarer''' converts from the massive {{{HsSyn}}} type to [wiki:Commentary/Compiler/CoreSynType GHC's intermediate language, CoreSyn].  This data type is relatively tiny: just eight constructors. 
     17 * The '''desugarer''' converts from the massive {{{HsSyn}}} type to [wiki:Commentary/Compiler/CoreSynType GHC's intermediate language, CoreSyn].  This Core-language data type is unusually tiny: just eight constructors. 
    1818 
    19  * The '''SimplCore''' pass ([[GhcFile(simplCore/SimplCore.lhs)]]) is a bunch of Core-to-Core passes that optimise the program.  The main passes are: 
    20     * 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. 
    21     * The '''float-out''' and '''float-in''' transformations, which move let-bindings outwards and inwards respectively. 
    22     * The '''strictness analyser'''.  This actually comprises two passes: the '''analayser''' itself and the '''worker/wrapper''' transformation that uses the results of the analysis to transform the program. 
    23     * The '''liberate-case''' transformation. 
    24     * The '''constructor-specialialisation''' transformation. 
     19 This late desugaring is somewhat unusual.  It is much more common to desugar the program before typechecking, or renaming, becuase that presents the renamer and typechecker with a much smaller language to deal with.  However, GHC's organisation means that (a) error messages can display precisely the syntax that the user wrote; and (b) desugaring is not required to preserve type-inference properties. 
     20 
     21 * The '''SimplCore''' pass ([[GhcFile(simplCore/SimplCore.lhs)]]) is a bunch of Core-to-Core passes that optimise the program.  The main passes are:[[BR]][[BR]] 
     22    * 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.  Two papers describe some of the implementation details: [http://research.microsoft.com/%7Esimonpj/Papers/comp-by-trans-scp.ps.gz A transformation-based optimiser for Haskell (SCP'98)], and [http://research.microsoft.com/%7Esimonpj/Papers/inlining/index.htm Secrets of the Glasgow Haskell Compiler inliner (JFP'02)].[[BR]][[BR]] 
     23    * The '''float-out''' and '''float-in''' transformations, which move let-bindings outwards and inwards respectively.  See [http://research.microsoft.com/%7Esimonpj/papers/float.ps.gz Let-floating: moving bindings to give faster programs (ICFP '96)].[[BR]][[BR]] 
     24    * The '''strictness analyser'''.  This actually comprises two passes: the '''analayser''' itself and the '''worker/wrapper''' transformation that uses the results of the analysis to transform the program.  The same analyser also does [http://research.microsoft.com/%7Esimonpj/Papers/cpr/index.htm Constructed Product Result analysis].[[BR]][[BR]] 
     25    * The '''liberate-case''' transformation.[[BR]][[BR]] 
     26    * The '''constructor-specialialisation''' transformation.[[BR]][[BR]] 
    2527    * The '''common sub-expression eliminiation''' (CSE) transformation. 
    2628