Changes between Version 18 and Version 19 of Commentary/Compiler/NewCodeGen


Ignore:
Timestamp:
May 16, 2008 3:36:20 PM (7 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/NewCodeGen

    v18 v19  
    7979   * Consider (sometime): block duplication.  branch to K; and K is a short block.  Branch chain elimination is just a special case of this.
    8080
    81  * '''The Adams optimisation'''.  Given:
     81
     82 * '''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.
     83    * The analysis produces a set of `BlockId` that should become proc-point
     84    * The transformation inserts a `CopyIn` at the start of each proc-point, and a `CopyOut` just before each branch to a proc-point.
     85
     86 * '''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. 
     87 Invariant: (something like) all variables in a block are gotten from `CopyIn` or `Reload`.
     88
     89 * '''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.
     90
     91 * '''Lay out the stack'''
     92   * 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.
     93   * A particular variable has one and only one `SlotId`. 
     94   * The stack layout pass produces a mapping of: ''(variable -> slotid, label -> slotid)''
     95   * Plus, it transforms the code by eliminating `CopyIn` and `CopyOut` in favour of assigments
     96
     97 * '''Make the stack explicit'''.
     98   * Convert `Spill`, `Reload` to hardware-register and stack traffic.
     99   * Add stack-pointer adjustment instructions.
     100   * Avoid memory traffic at joins. (What does this mean?)
     101
     102 * '''Split into multiple !CmmProcs'''.
     103
     104
     105'''The Adams optimisation''' is done by stuff above.  Given:
    82106{{{
    83107  call f returns to K
     
    91115}}}
    92116 ''and'' move `CopyOut` into L's other predecessors.  !ToDo: explain why this is a good thing.  In fact Common Block Elimination does this, we think.
    93 
    94  * '''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.
    95     * The analysis produces a set of `BlockId` that should become proc-point
    96     * The transformation inserts a `CopyIn` at the start of each proc-point, and a `CopyOut` just before each branch to a proc-point.
    97 
    98  * '''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. 
    99  Invariant: (something like) all variables in a block are gotten from `CopyIn` or `Reload`.
    100 
    101  * '''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.
    102 
    103  * '''Make the stack explicit'''.
    104    * Convert `CopyIn`, `CopyOut`, `Spill`, `Reload` to hardware-register and stack traffic.
    105    * Add stack-pointer adjustment instructions.
    106    * Avoid memory traffic at joins. (What does this mean?)
    107 
    108  * '''Split into multiple !CmmProcs'''.
    109117
    110118-----------------------------------