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.