Changes between Version 16 and Version 17 of Commentary/Compiler/IntegratedCodeGen


Ignore:
Timestamp:
Jun 9, 2008 10:18:50 AM (6 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/IntegratedCodeGen

    v16 v17  
    6565== Proposed compilation pipeline == 
    6666 
    67  0. Convert from {{{STG}}} to an abstract {{{CmmAgraph}}} ([[GhcFile(compiler/cmm/ZipCfg.hs)]], [[GhcFile(compiler/cmm/ZipCfgCmmRep.hs)]]).  This step is Simon PJ's "new code generator" from September 2007.  One departure from the old code generator is that '''we do not build a {{{Cmm}}} abstract-syntax tree;''' instead we go straight to a control-flow graph. 
    68  0. Reify the control-flow graph in a non-abstract form that can be analyzed, transformed, and optimized: convert {{{CmmAgraph -> CmmGraph}}}.  This conversion may introduce new variables, stack slots, and compile-time constants.  
     67 0. Convert from {{{STG}}} to an control flow graph {{{CmmGraph}}} ([[GhcFile(compiler/cmm/ZipCfg.hs)]], [[GhcFile(compiler/cmm/ZipCfgCmmRep.hs)]]).  This step is Simon PJ's "new code generator" from September 2007.  This conversion may introduce new variables, stack slots, and compile-time constants.  
    6968   * Implements calling conventions for call, jump, and return instructions: all parameter passing is turned into data-movement instructions (register-to-register move, load, or store), and stack-pointer adjustments are inserted. After this point, calls, returns, and jumps are just control-transfer instructions -- the parameter passing has been compiled away.   
    70    * How do we refer to locations on the stack when we haven't laid it out yet? The compiler names a stack slot using the idea of a "late compile-time constant," which is just a symbolic constant that will be replaced with an actual stack offset when the stack layout is chosen. 
     69   * How do we refer to locations on the stack when we haven't laid it out yet? The compiler names a stack slot using the idea of a "late compile-time constant," which is just a symbolic constant that will be replaced with an actual stack offset when the stack layout is chosen.One departure from the old code generator is that '''we do not build a {{{Cmm}}} abstract-syntax tree;''' instead we go straight to a control-flow graph. 
     70 In practice, we first generate an "abstract control flow graph", `CmmAGraph`, which makes the business of generating fresh `BlockId`s more convenient, and convert that to a `CmmGraph`.  The former is convenient for ''construction'' but cannot be analysed; the latter is concrete, and can be analyzed, transformed, and optimized.   
    7171 0. Instruction selection: each {{{Cmm}}} {{{Middle}}} and {{{Last}}} node in the control-flow graph is replaced with a new graph in which the nodes are machine instructions.  The {{{MachineMiddle}}} type represents computational machine instructions; the {{{MachineLast}}} type represents control-transfer instructions.  The choice of representation is up to the author of the back end, but for continuity with the existing native code generators, we expect to begin by using algebraic data types inspired by the existing definitions in [[GhcFile(compiler/nativeGen/MachInstrs.hs)]]. 
    7272      * An '''extremely important distinction''' from the existing code is that we plan to eliminate {{{#ifdef}}} and instead provide multiple datatypes, e.g., in {{{I386Instrs.hs}}}, {{{PpcInstrs.hs}}}, {{{SparcInstrs.hs}}}, and so on.