Changes between Version 64 and Version 65 of Commentary/Compiler/StackAreas


Ignore:
Timestamp:
Jul 2, 2008 11:59:27 AM (6 years ago)
Author:
dias
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/StackAreas

    v64 v65  
    6666 
    6767 
    68 The following image shows the layout of a `CallArea` for both the outgoing parameters (function call) and incoming results (continuation after returning from the function call). Note that the incoming and outgoing parameters may be different, and they may overlap. 
     68The following figure shows the layout of a `CallArea` for both the outgoing parameters (function call) and incoming results (continuation after returning from the function call). Note that the incoming and outgoing parameters may be different, and they may overlap. 
    6969 
    7070[[Image(CallArea.png)]] 
     
    9696 1. Walk over the graph, keeping track of the stack pointer, and rewrite each address of a stack slot with an offset from the stack pointer. 
    9797 
    98 One way to assign stack slots is to traverse the flow graph in a reverse post-order depth-first search, allocating a stack location to each stack slot the first time we encounter the slot. (Note: When we encounter a parameter-passing area for the first time, we allocate stack locations for the whole area.) The allocation is then reused for every reference to the stack slot. 
     98One way to assign stack slots is to traverse the flow graph in a reverse post-order depth-first search, allocating stack slots to each `Area`. Subsequently, when we see an `Area` again, we reuse the previous allocation. A stack slot is allocated the first time we encounter: 
     99 * A use or definition of a `RegSlot` for a variable 
     100 * A call site, where we allocate stack slots for the `CallArea` associated with the return continuation. Note that we cannot allocate stack slots for a `CallArea` when we first see a use or definition of a slot in the `CallArea`. Why? At a call site, the `CallArea` holding the function arguments must be the youngest live area on the stack. If we were to eagerly allocate stack slots for the `CallArea`, we wouldn't know how much space to leave on the stack for variable spills that we will yet encounter on the path to the call site. By waiting until we reach the call site, we can be sure that we have already seen all the variables that are spilled before the call site. 
     101 
     102 
     103 
    99104 
    100105The algorithm keeps two pieces of information: