Changes between Version 33 and Version 34 of Commentary/Compiler/NewCodeGen


Ignore:
Timestamp:
Sep 1, 2008 3:00:46 PM (7 years ago)
Author:
dias
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/NewCodeGen

    v33 v34  
    3535   * Common block elimination: done 
    3636   * Block concatenation: done 
    37  * 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. 
    38  * Proc-point analysis and transformation: 'working' but largely untested.  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: 
     37 * Adams optimisation: currently done in [[GhcFile(compiler/cmm/CmmProcPointZ.hs.  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. 
     38 * Proc-point analysis and transformation: working, although there is plenty of room for experimentation with the calling conventions at proc points.  In practice NR recommends the following procedure: 
    3939    * All optional proc points to be generated with no parameters (all live variables on the stack) 
    4040    * 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 
     41 * Bypassing proc-point analysis for native back ends: not done. 
    4142 * 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) 
    42  * 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. John has done much of the work here already; the remaining bit is the actual layout of the stack slots. 
     43 * Stack slot allocation: implemented with a greedy algorithm. There is room for improvement here. 
    4344 * Make stack explicit: done. 
    44  * Split into multiple !CmmProcs: mostly done, just a bit of patching up remains. 
    45  
    46 Norman's plan 
    47  0. New code to check invariants of output from [[GhcFile(compiler/cmm/ZipDataflow.hs)]] 
    48  0. Finish debugging [[GhcFile(compiler/cmm/ZipDataflow.hs)]]. 
    49  0. Use Simon PJ's 'common-blockifier' (which does not exist!!!) to move the Adams optimization outside [[GhcFile(compiler/cmm/CmmProcProintZ.hs)]] 
    50  0. ProcPointZ does not insert `CopyOut` nodes; this omission must be rectified and will require some general infrastructure for inserting predecessors. 
    51  0. Simple optimizations on `CopyIn` and `CopyOut` may be required 
    52  0. Define an interface for calling conventions and invariants for the output of frame layout [will require help from Simon M] 
    53  0. Stack layout 
    54  0. Glue the whole pipeline together and make sure it works. 
    55  
    56 Items 1-5 look like a few days apiece. Items 6 and 7 are more scary... 
     45 * Split into multiple !CmmProcs: done. 
    5746 
    5847!ToDo: main issues 
    59  * SRTs simply record live global variables.  So we should use the same live-variable framework as for live local variables.  That means we must be able to identify which globals are SRT-able.  What about compression/encoding schemes? 
     48 * SRTs simply record live global variables.  So we should use the same live-variable framework as for live local variables.  That means we must be able to identify which globals are SRT-able.  What about compression/encoding schemes? Status: live variables are finished, but the actual SRT tables aren't right -- need to write new code that can handle recursive let bindings. 
    6049 
    6150 * How do we write continuations in the RTS?  E.g. the update-frame continuation?  Michael Adams had a syntax with two sets of parameters, the the ones on the stack and the return values. 
     
    6352 * Review code gen for calls with lots of args.  In the existing codegen we push magic continuations that say "apply the return value to N more args".  Do we want to do this?  !ToDo: how rare is it to have too many args? 
    6453 
    65  * Figure out how PAPs work.  This may interact with the GC check and stack check at the start of a function call. 
     54 * Figure out how PAPs work.  This may interact with the GC check and stack check at the start of a function call.  The concern is how to enter the garbage collector with an infotable that properly describes the live variables. Now that we generate info tables on demand at the end of the pipeline, we can enter the gc with a regular procedure call and expect that the proper info table will be generated. 
    6655 
    67  * How do stack overflow checks work?  (They are inserted by the CPS conversion, and must not generate a new info table etc.) 
     56 * How do stack overflow checks work?  A stack check is inserted during the conversion from Stg to Cmm, with a proxy constant standing for the stack high-water mark. It is replaced when the stack pointer is reified. Status: Todo. 
    6857 
    6958  * Was there something about sinking spills and hoisting reloads? 
     
    7261!ToDo: small issues 
    7362 * Shall we rename Branch to !GoTo?! 
    74  * Where is the "push new continuation" middle node?  
     63 * Where is the "push new continuation" middle node? It's gone! 
    7564 * Change the C-- parser (which parses RTS .cmm files) to directly construct `CmmGraph`.   
    7665 * (SLPJ) See let-no-escape todos in `StgCmmExpr`.