Changes between Version 13 and Version 14 of Commentary/Compiler/NewCodeGen


Ignore:
Timestamp:
Jan 21, 2008 5:34:51 PM (6 years ago)
Author:
guest
Comment:

added some hard links to real source files

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/NewCodeGen

    v13 v14  
    99   * Common block elmination: to do 
    1010   * Block concatenation: to do 
    11  * Adams optimisation: currently done in cmm/CmmProcPointZ, which is incomplete because it does not insert the correct CopyOut nodes.  The Adams optimization should be divorced from this module and replaced with common-block elimination, to be done after the proc-point transformation.  In principle this combination may be slightly less effective than the current code, since the selection of proc-point protocols is guided by Adams's criteria, but NR thinks it will be easy to get the common, important cases nailed. 
     11 * Adams optimisation: currently done in [[GhcFile(compiler/cmm/CmmProcPointZ.hs)]], which is incomplete because it does not insert the correct CopyOut nodes.  The Adams optimization should be divorced from this module and replaced with common-block elimination, to be done after the proc-point transformation.  In principle this combination may be slightly less effective than the current code, since the selection of proc-point protocols is guided by Adams's criteria, but NR thinks it will be easy to get the common, important cases nailed. 
    1212 * Proc-point analysis and transformation: 'working' but incomplete and incorrect in the sense that CopyIn nodes are created without all the required dual CopyOut nodes.  There is still no coherent plan for calling conventions, and the lack of such a plan prevents the completion of proc-point analysis, as in principle it should come up with a calling convention for each freely chosen proc point.  In practice NR recommends the following procedure: 
    1313    * All optional proc points to be generated with no parameters (all live variables on the stack) 
    1414    * This situation to be remedied when the code generator is reorganized along the lines NR proposed in July 2007, i.e., the register allocator runs on C-- with calls (as opposed to C-- with jumps only) and therefore ''before'' proc-point analysis 
    15  * Add spill/reload: Implemented to NR's satisfaction in cmm/CmmSpillReload.hs, with the proviso that spilling is done to ''abstract'' stack slots rather than real stack positions (see comments below on stack-slot allocation) 
     15 * Add spill/reload: Implemented to NR's satisfaction in [[GhcFile(compiler/cmm/CmmSpillReload.hs)]], with the proviso that spilling is done to ''abstract'' stack slots rather than real stack positions (see comments below on stack-slot allocation) 
    1616 * Stack slot allocation: nothing here but some broken bits and pieces.  Progress in this arena is blocked by the lack of a full understanding of how to do stack-frame layout and how to deal with calling conventions.  NR proposes that life would be simplified if ''all'' calls downstream from the Cmm converter were to be parameterless---the idea being to handle the calling conventions ''here'' and to put arguments and results in their conventional locations. 
    1717 * Make stack explicit: to do 
     
    1919 
    2020Norman's plan 
    21  0. New code to check invariants of output from `ZipDataflow` 
    22  0. Finish debugging `ZipDataflow` 
    23  0. Use Simon PJ's 'common-blockifier' (which does not exist!!!) to move the Adams optimization outside `CmmProcProintZ` 
     21 0. New code to check invariants of output from [[GhcFile(compiler/cmm/ZipDataflow.hs)]] 
     22 0. Finish debugging [[GhcFile(compiler/cmm/ZipDataflow.hs)]]. 
     23 0. Use Simon PJ's 'common-blockifier' (which does not exist!!!) to move the Adams optimization outside [[GhcFile(compiler/cmm/CmmProcProintZ.hs)]] 
    2424 0. ProcPointZ does not insert `CopyOut` nodes; this omission must be rectified and will require some general infrastructure for inserting predecessors. 
    2525 0. Simple optimizations on `CopyIn` and `CopyOut` may be required 
     
    5454There is a new Cmm data type: 
    5555 
    56  * '''`ZipCfg`''' contains a generic zipper-based control-flow graph data type.  It is generic in the sense that it's polymorphic in the type of '''middle nodes''' and '''last nodes''' of a block.  (Middle nodes don't do control transfers; last nodes only do control transfers.)  There are extensive notes at the start of the module.[[BR]][[BR]] 
     56 * [[GhcFile(compiler/cmm/ZipCfg.hs)]] contains a generic zipper-based control-flow graph data type.  It is generic in the sense that it's polymorphic in the type of '''middle nodes''' and '''last nodes''' of a block.  (Middle nodes don't do control transfers; last nodes only do control transfers.)  There are extensive notes at the start of the module.[[BR]][[BR]] 
    5757 The key types it defines are: 
    5858   * Block identifiers: `BlockId`, `BlockEnv`, `BlockSet` 
     
    6060   * Control-flow graphs: `Graph`[[BR]][[BR]] 
    6161 * '''`ZipDataFlow`''' contains a generic framework for solving dataflow problems over `ZipCfg`.[[BR]][[BR]] 
    62  * '''`ZipCfgCmm`''' instantiates `ZipCfg` for Cmm, by defining types `Middle` and `Last` and using these to instantiate the polymorphic fields of `ZipCfg`.  It also defines a bunch of smart constructor (`mkJump`, `mkAssign`, `mkCmmIfThenElse` etc) which make it easy to build `CmmGraph`.[[BR]][[BR]] 
     62 * '''[[GhcFile(compiler/cmm/ZipCfgCmmRep.hs)]]''' instantiates `ZipCfg` for Cmm, by defining types `Middle` and `Last` and using these to instantiate the polymorphic fields of `ZipCfg`.  It also defines a bunch of smart constructor (`mkJump`, `mkAssign`, `mkCmmIfThenElse` etc) which make it easy to build `CmmGraph`.[[BR]][[BR]] 
    6363 * '''`CmmExpr`''' contains the data types for Cmm expressions, registers, and the like.  It does not depend on the dataflow framework at all. 
    6464