Changes between Version 43 and Version 44 of Commentary/Compiler/NewCodeGenPipeline


Ignore:
Timestamp:
Feb 1, 2014 3:54:12 PM (16 months ago)
Author:
jstolarek
Comment:

Move CmmPipeline description to CodeGenerator page

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/NewCodeGenPipeline

    v43 v44  
    2020== The Cmm pipeline ==  
    2121 
    22 The first two steps are described in more detail here: 
    23  
    24  * '''Code generator''' converts STG to `CmmGraph`.  Implemented in `StgCmm*` modules (in directory `codeGen`).  
    25    * `Cmm.CmmGraph` is pretty much a Hoopl graph of `CmmNode.CmmNode` nodes. Control transfer instructions are always the last node of a basic block. 
    26    * Parameter passing is made explicit; the calling convention depends on the target architecture.  The key function is `CmmCallConv.assignArgumentsPos`.  
    27      * Parameters are passed in virtual registers R1, R2 etc. [These map 1-1 to real registers.]  
    28      * Overflow parameters are passed on the stack using explicit memory stores, to locations described abstractly using the [wiki:Commentary/Compiler/StackAreas ''Stack Area'' abstraction.].    
    29      * Making the calling convention explicit includes an explicit store instruction of the return address, which is stored explicitly on the stack in the same way as overflow parameters. This is done (obscurely) in `MkGraph.mkCall`. 
    30  
    31  * '''Simple control flow optimisation''', implemented in `CmmContFlowOpt`.  It's called both at the beginning and end of the pipeline. 
    32    * Branch chain elimination. 
    33    * Remove unreachable blocks. 
    34    * Block concatenation.  branch to K; and this is the only use of K.   
    35  
    36  * '''More control flow optimisations'''. 
    37    * Common Block Elimination (like CSE). This essentially implements the Adams optimisation, we believe. 
    38    * Consider (sometime): block duplication.  branch to K; and K is a short block.  Branch chain elimination is just a special case of this. 
    39  
    40  * '''Proc-point analysis''' and '''transformation''', implemented in `CmmProcPoint`. The transformation part adds a function prologue to the front of each proc-point, following a standard entry convention. 
    41     * The analysis produces a set of `BlockId` that should become proc-points 
    42     * The transformation inserts a function prologue at the start of each proc-point, and a function epilogue just before each branch to a proc-point. 
     22Description of Cmm pipeline has been moved to [wiki:Commentary/Compiler/CodeGen Code Generator] page. Below are descriptions of two passes that at some point existed in the Cmm pipeline of the new code generator but were later removed and didn't make it into GHC 7.8 (first stable release with the new codegen). 
    4323 
    4424 * '''(OUTDATED - !CmmSpillReload does not exist any more)''' '''Add spill/reload''', implemented in `CmmSpillReload`, to spill live C-- variables before a call and reload them afterwards.  The spill and reload instructions are simply memory stores and loads respectively, using symbolic stack offsets (see [wiki:Commentary/Compiler/StackAreas#Layingoutthestack stack layout]).  For example, a spill of variable 'x' would look like `Ptr32[SS(x)] = x`. 
     
    5333   * Sink or inline assignments nearer their use points 
    5434   * Do constant mach-op folding. This is done in this phase, because folded mach-ops can be inlined, and inlining exposes opportunities for mach-op folding. 
    55  
    56  * '''Remove dead assignments and stores''', implemented in `CmmLive`, removes assignments to dead variables and things like ``a = a`` or ``I32[Hp] = I32[Hp]``. The latter may more appropriately be done in a general optimization pass, as it doesn't take advantage of liveness information. 
    57  
    58  * '''Figure out the stack layout''', implemented in `CmmStackLayout`. 
    59    * Each variable 'x', and each proc-point label 'K', has an associated ''Area'', written SS(x) and SS(k) resp, that names a contiguous portion of the stack frame.   
    60    * The stack layout pass produces a mapping of: ''(`Area` -> `StackOffset`)''. For more detail, see [wiki:Commentary/Compiler/StackAreas#Layingoutthestack the description of stack layout.] 
    61    * A `StackOffset` is the byte offset of a stack slot from the old end (high address) of the frame.  It doesn't vary as the physical stack pointer moves. 
    62  
    63  * '''Manifest the stack pointer''', implemented in `CmmStackLayout`.  Once the stack layout mapping has been determined, a second pass walks over the graph, making the stack pointer, `Sp` explicit. Before this pass, there is no `Sp` at all.  After this, `Sp` is completely manifest. 
    64    * replacing references to `Areas` with offsets from `Sp`. 
    65    * adding adjustments to `Sp`. 
    66   
    67  * '''Split into multiple !CmmProcs''', implemented in `CmmProcPointZ`.  At this point we build an info-table for each of the !CmmProcs, including SRTs.  Done on the basis of the live local variables (by now mapped to stack slots) and live CAF statics. 
    68    * `LastCall` and `LastReturn` nodes are replaced by `Jump`s. 
    69  
    70  * '''Build info tables''', implemented in `CmmBuildInfoTables`..   
    71    * Find each safe `MidForeignCall` node, "lowers" it into the suspend/call/resume sequence (see `Note [Foreign calls]` in `CmmNode.hs`.), and build an info table for them. 
    72    * Convert the `CmmInfo` for each `CmmProc` into a `[CmmStatic]`, using the live variable information computed just before "Figure out stack layout".   
    7335 
    7436=== Branches to continuations and the "Adams optimisation" ===