Changes between Version 5 and Version 6 of Commentary/Compiler/Demand


Ignore:
Timestamp:
Sep 17, 2012 10:49:21 AM (3 years ago)
Author:
ilya
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/Demand

    v5 v6  
    3434indicates that the function has one parameter, which is used lazily (hence `<L,U>`), however, when its result is used strictly, the free variable `skY` in its body is also used strictly. 
    3535 
    36 === Demand description === 
     36=== Demand descriptions === 
    3737 
    3838Strictness demands 
     
    6969== Worker-Wrapper split == 
    7070 
    71 [TODO] 
     71Demand analysis in GHC drives the ''worker-wrapper transformation'',  which exposes specialised calling conventions  to the rest of the compiler.  In particular, the  worker-wrapper transformation implements the unboxing optimisation. 
     72 
     73The worker-wrapper transformation splits each  
     74function `f` into a ''wrapper'', with the 
     75ordinary calling convention, and a ''worker'', with a specialised 
     76calling convention.  The wrapper serves as an impedance-matcher to the 
     77worker; it simply calls the worker using the specialised calling convention. 
     78The transformation can be expressed directly in GHC's intermediate language. 
     79Suppose that `f` is defined thus: 
     80{{{ 
     81  f :: (Int,Int) -> Int 
     82  f p = <rhs> 
     83}}} 
     84and that we know that `f` is strict in its argument (the pair, that is), 
     85and uses its components. 
     86What worker-wrapper split shall we make? Here is one 
     87possibility: 
     88{{{ 
     89 f :: (Int,Int) -> Int 
     90  f p = case p of 
     91          (a,b) -> $wf a b 
     92 
     93  $wf :: Int -> Int -> Int 
     94  $wf a b = let p = (a,b) in <rhs> 
     95}}} 
     96Now the wrapper, `f`, can be inlined at every call site, so that 
     97the caller evaluates `p`, passing only the components to the worker  
     98`$wf`, thereby implementing the unboxing transformation. 
     99 
     100 
     101But what if `f` did not use `a`, or `b`?  Then it would be silly to 
     102pass them to the worker `$wf`.  Hence the need for absence 
     103analysis.  Suppose, then, that we know that `b` is not needed. Then 
     104we can transform to: 
     105{{{ 
     106  f :: (Int,Int) -> Int 
     107  f p = case p of (a,b) -> $wf a 
     108 
     109  $wf :: Int -> Int 
     110  $wf a = let p = (a,error "abs") in <rhs> 
     111}}} 
     112Since `b` is not needed, we can avoid passing it from the wrapper to 
     113the worker; while in the worker, we can use `error "abs"` instead of 
     114`b`. 
     115 
     116 
     117In short, the worker-wrapper transformation allows the knowledge 
     118gained from strictness and absence analysis to be exposed to the rest 
     119of the compiler simply by performing a local transformation on the 
     120function definition.  Then ordinary inlining and case elimination will 
     121do the rest, transformations the compiler does anyway. 
     122 
    72123 
    73124== Relevant compiler parts ==