Changes between Version 42 and Version 43 of Commentary/Compiler/StackAreas


Ignore:
Timestamp:
Jun 26, 2008 4:44:56 PM (6 years ago)
Author:
dias
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/StackAreas

    v42 v43  
    99=== Representing Stack Slots === 
    1010 
    11 ==== The old approach ==== 
    12  
    13  
    14 In the old code generator, we have a phase ordering problem: no compiler phase can name a stack slot until stack layout has been fixed. But stack layout can only be fixed at the end of the pipeline. The consequence of this approach is that most of the pipeline requires special treatment for code that must refer to stack slots (e.g. parameter passing in calling conventions, or spills and reloads). In particular, we defined special instructions for !CopyIn and !CopyOut of function arguments, which implicitly stand for an adjustment to the stack pointer and some parallel assignments to the function parameters or return results. 
    15  
    16 For example, we compile a function call 
    17  
    18 {{{ 
    19 x, y = f(a, b, c); 
    20 }}} 
    21  
    22 into the following C--: 
    23  
    24 {{{ 
    25   CopyOut(a, b, c); 
    26   call f returns to k; 
    27 k: 
    28   CopyIn (x, y) 
    29 }}} 
    30  
    31 Every stage of the back end must cope with the !CopyIn and !CopyOut pseudoinstructions. 
    32  
    33 ==== The new approach ==== 
    34  
    35 A better approach is to introduce a unique name for each stack slot, then treat the name as the addressing expression for the slot. At the end of the pipeline, we choose a stack layout, then replace each stack slot with its offset from the stack pointer. The benefit is that we break the phase-ordering problem: any phase of the compiler can name a stack slot. 
     11For each stack slot, we introduce a new name, then treat the name as the addressing expression for the slot. At the end of the pipeline, we choose a stack layout, then replace each stack slot with its offset from the stack pointer. The benefit is that we break the phase-ordering problem: any phase of the compiler can name a stack slot. 
    3612 
    3713For example, if we want to spill a variable {{{x}}}, we use a regular store instruction to a stack slot at address {{{stack<x>}}}: 
     
    6339}}} 
    6440 
    65 Note that the semantics of the now-unnecessary !CopyIn and !CopyOut are reified by an assignment to the stack pointer and a series of copy instructions. If an optimization understands copy instructions, it can improve this code -- without having to worry about the semantics of !CopyIn. 
    66  
    67 Furthermore, the job of laying out the stack is now pleasantly simple: decide where to place the slots and parameter-passing areas, then rewrite the references to stack locations. The stack-layout phase is no longer responsible for inserting stack adjustments or lowering !CopyIn and !CopyOut nodes to data-movement instructions. 
    68  
    6941We use the following types to represent stack slots and parameter-passing areas: 
    7042 
     
    8254}}} 
    8355 
    84 An {{{Area}}} represents space on the stack; it may use either the {{{RegSlot}}} constructor to represent a single stack slot for a register or the {{{CallArea}}} constructor to represent parameters passed to/from a function call/return. In a {{{CallArea}}}, the {{{BlockId}}} is the label of the function call's continuation, and the two integers are the sizes of the outgoing and incoming parameter-passing areas. 
     56An `Area` represents space on the stack; it may use either the `RegSlot` constructor to represent a single stack slot for a register or the `CallArea` constructor to represent parameters passed to/from a function call/return. In a `CallArea`, the `BlockId` is the label of the function call's continuation, and the two integers are the sizes of the outgoing and incoming parameter-passing areas. 
    8557 
    86 To name a specific location on the stack, we represent its address with a new kind of {{{CmmExpr}}}: the {{{CmmStackSlot}}}. A {{{CmmStackSlot}}} is just an integer offset into an {{{Area}}}. If the {{{Area}}} is a {{{RegSlot}}}, it is a dynamic invariant that the offset must be {{{0}}}. 
     58To name a specific location on the stack, we represent its address with a new kind of `CmmExpr`: the `CmmStackSlot`. A `CmmStackSlot` is just an integer offset into an `Area`. If the `Area` is a `RegSlot`, we might still use a non-zero offset: for example, we might want to load the low word from a long integer. 
    8759 
    8860Notice that a `CmmStackSlot` is an ''address'', so we can say