Changes between Version 2 and Version 3 of Commentary/Compiler/StackAreas


Ignore:
Timestamp:
May 16, 2008 7:01:55 PM (6 years ago)
Author:
dias
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/StackAreas

    v2 v3  
    1010 
    1111A much better approach is to give symbolic names to locations on the stack, lower all the argument passing and stack adjusting to the actual data-movement instructions, and replace the names later when the final stack layout is fixed. 
     12 
     13For example 
     14{{{ 
     15f(x) { 
     16   y = x; 
     17   ... 
     18 
     19   call g(x) returning to L; 
     20 
     21 L: 
     22   ... 
     23} 
     24}}} 
     25 
     26should be compiled to 
     27 
     28{{{ 
     29f: 
     30   x = m[stack(f, 1)]; // copy the argument from stack area `f' to  
     31   y = x; 
     32 
     33   ... 
     34 
     35   sp = stack(L, 1); // Make room on the stack for the arguments 
     36   m[stack(L, 1)] = x; // copy the argument 
     37   m[stack(L, 0)] = L; 
     38   call g(); 
     39 
     40 L: 
     41   ...  
     42} 
     43}}} 
     44 
     45The exact syntax will probably be a bit different, making the representation of the stack slots abstract, but there's the gist of it. 
     46 
     47Ah, but do we assign stack slots? As it turns out, an important optimization in GHC is to use return values as stack slots whenever possible. For example, given the program 
     48 
     49{{{ 
     50f() { 
     51  x = g(); 
     52  ... 
     53} 
     54}}} 
     55 
     56If g() returns x on the stack, we would like the return location be used as x's stack slot for the rest of the procedure. 
     57Issues raised by this (to be expounded upon): 
     58 * Stack holes where return addresses were stored. Such a hole can be filled with a variable that can't be stored in a convenient return slot. 
     59 * Stack allocation must be based on control flow -- how else would you know if x has already been placed or if it can be stored on the bottom of the stack? 
     60  
     61Ah! Here's an argument for making the stack slots abstract and unique, instead of referring to two values that share the same stack slot (e.g. a call parameter and a return parameter) by the same name. Another apparently important GHC optimization is to keep a return address live on the stack if it can be reused in a subsequent call. It would be really easy to say that an abstract stack slot is live. But it's not so easy if the only way to name the slot is by its (non-distinct) address stack(L, 3) because stack(L, 3) may also be used by some other value that shares the same slot.