Changes between Version 3 and Version 4 of Commentary/Compiler/NewCodeGenPipeline


Ignore:
Timestamp:
Jun 26, 2008 2:56:53 PM (7 years ago)
Author:
dias
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/NewCodeGenPipeline

    v3 v4  
    22== The pipeline: Make the new code generator work with the existing native codeGen == 
    33 
    4  * '''Code generator''' converts STG to `CmmGraph`.  Implemented in `StgCmm*` modules (in directory `codeGen`). 
    5    * TODO: Make parameter passing and stack adjustments explicit using the [wiki:Commentary/Compiler/StackAreas ''Stack Area'' abstraction.] 
     4 * '''Code generator''' converts STG to `CmmGraph`.  Implemented in `StgCmm*` modules (in directory `codeGen`). Parameter passing and stack adjustments are made explicit using the [wiki:Commentary/Compiler/StackAreas ''Stack Area'' abstraction.] 
     5   * TODO: Use the proper calling conventions (post Rep Swamp). 
    66 
    77 * '''Simple control flow optimisation''', implemented in `CmmContFlowOpt`: 
     
    1212   * Consider (sometime): block duplication.  branch to K; and K is a short block.  Branch chain elimination is just a special case of this. 
    1313 
    14  * '''Proc-point analysis''' and '''transformation''', implemented in `CmmProcPointZ`.  (Adams version is `CmmProcPoint`.) The transformation part adds a `CopyIn` to the front of each proc-point, which expresses the idea that proc-points use a standard entry convention. 
    15     * The analysis produces a set of `BlockId` that should become proc-point 
    16     * The transformation inserts a `CopyIn` at the start of each proc-point, and a `CopyOut` just before each branch to a proc-point. 
     14 * '''Proc-point analysis''' and '''transformation''', implemented in `CmmProcPointZ`.  (Adams version is `CmmProcPoint`.) The transformation part adds a function prologue to the front of each proc-point, following a standard entry convention. 
     15    * The analysis produces a set of `BlockId` that should become proc-points 
     16    * 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. 
    1717 
    1818 * '''Add spill/reload''', implemented in `CmmSpillReload`, to spill live C-- variables before a call and reload them afterwards.  The middle node of the result is `Middle` (from `ZipCfgCmm` extended with `Spill` and `Reload` constructors.   
    1919 Invariant: (something like) all variables in a block are gotten from `CopyIn` or `Reload`.  
    2020 
    21  * '''Stack slot layout'''.  Build inteference graph for variables live across calls, and allocate a stack slot for such variables.  That is, stack slot allocation is very like register allocation. 
    22  
    2321 * '''Lay out the stack''' 
    2422   * A `SlotId` is the offset of a stack slot from the old end (high address) of the frame.  It doesn't vary as the physical stack pointer moves. 
    2523   * A particular variable has one and only one `SlotId`.   
    26    * The stack layout pass produces a mapping of: ''(variable -> slotid, label -> slotid)'' 
    27    * Plus, it transforms the code by eliminating `CopyIn` and `CopyOut` in favour of assigments 
    28  
    29  * '''Make the stack explicit'''.  
    30    * Convert `Spill`, `Reload` to hardware-register and stack traffic. 
    31    * Add stack-pointer adjustment instructions. 
    32    * Avoid memory traffic at joins. (What does this mean?) 
     24   * The stack layout pass produces a mapping of: ''(Area -> slotid)''. See [wiki:Commentary/Compiler/StackAreas#Layingoutthestack.] 
     25   * Walk over the graph, replacing references to stack areas with offsets from the stack pointer. 
    3326 
    3427 * '''Split into multiple !CmmProcs'''.  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.