lambda lifting chapter done

Author: doyougnu

bib/book.bib

@@ -1,3 +1,22 @@
+@inproceedings{compilingWithoutCont,
+author = {Maurer, Luke and Downen, Paul and Ariola, Zena M. and Peyton Jones, Simon},
+title = {Compiling without Continuations},
+year = {2017},
+isbn = {9781450349888},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/3062341.3062380},
+doi = {10.1145/3062341.3062380},
+abstract = {Many fields of study in compilers give rise to the concept of a join point—a place where different execution paths come together. Join points are often treated as functions or continuations, but we believe it is time to study them in their own right. We show that adding join points to a direct-style functional intermediate language is a simple but powerful change that allows new optimizations to be performed, including a significant improvement to list fusion. Finally, we report on recent work on adding join points to the intermediate language of the Glasgow Haskell Compiler.},
+booktitle = {Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation},
+pages = {482–494},
+numpages = {13},
+keywords = {CPS, ANF, Haskell, GHC, list fusion, intermediate languages},
+location = {Barcelona, Spain},
+series = {PLDI 2017}
+}
+
+
 @article{jones1992implementing,
 author = {Jones, Peyton and L, Simon and Peyton Jones, Simon},
 title = {Implementing Lazy Functional Languages on Stock Hardware: The Spineless Tagless G-machine},
@@ -241,3 +260,20 @@ @misc{selectiveLambdaLifting
   year = {2019},
   copyright = {arXiv.org perpetual, non-exclusive license}
 }
+
+@inproceedings{fastCurry,
+author = {Marlow, Simon and Jones, Simon Peyton},
+title = {Making a Fast Curry: Push/Enter vs. Eval/Apply for Higher-Order Languages},
+year = {2004},
+isbn = {1581139055},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/1016850.1016856},
+doi = {10.1145/1016850.1016856},
+abstract = {Higher-order languages that encourage currying are implemented using one of two basic evaluation models: push/enter or eval/apply. Implementors use their intuition and qualitative judgements to choose one model or the other.Our goal in this paper is to provide, for the first time, a more substantial basis for this choice, based on our qualitative and quantitative experience of implementing both models in a state-of-the-art compiler for Haskell.Our conclusion is simple, and contradicts our initial intuition: compiled implementations should use eval/apply.},
+booktitle = {Proceedings of the Ninth ACM SIGPLAN International Conference on Functional Programming},
+pages = {4–15},
+numpages = {12},
+location = {Snow Bird, UT, USA},
+series = {ICFP '04}
+}

src/Optimizations/GHC_opt/lambda_lifting.rst

@@ -61,9 +61,9 @@ simply reference it; no closures needed!
 
    The fundamental tradeoff is decreased heap allocation for an increase in
    function parameters at each call site. This means that lambda lifting trades
-   heap for stack and is not always a performance win. See `When to Manually
-   Apply Lambda Lifting`_ for guidance on recognizing when your program may
-   benefit.
+   heap for stack and is not always a performance win. See :ref:`When to
+   Manually Apply Lambda Lifting <when>` for guidance on recognizing when your
+   program may benefit.
 
 
 How Lambda Lifting Works in GHC
@@ -89,8 +89,7 @@ details.
 
 GHC does not lambda lift:
 
-#. :term:`Top-level` bindings. By definition these
-   cannot be lifted.
+#.  A :term:`Top-level binding`. By definition these cannot be lifted.
 #. :term:`Thunk` and Data Constructors. Lifting either of these would destroy
    sharing.
 #. :term:`Join Point` because there is no lifting possible in a join point.
@@ -127,6 +126,8 @@ syntactic changes:
 #. All non-top-level variables (i.e., free variables) in the let's body become
    occurrences of parameters.
 
+.. _when:
+
 When to Manually Lambda Lift
 ----------------------------
 
@@ -205,11 +206,13 @@ function is called and allocated.
    function. Top level functions are always only allocated once.
 
 The next determining factor is counting the number of new parameters that will
-be passed to lifted function. Should this number become greater than the number
-of available argument registers on the target platform then you'll incur slow
-downs in the STG machine......
-
-tomorrow: update glossary, genapply and calling conventions. start here
+be passed to the lifted function. Should this number become greater than the
+number of available argument registers on the target platform then you'll incur
+slow downs in the STG machine. These slowdowns result from more work the STG
+machine will need to do. It will need to generate code that pops arguments from
+the stack instead of just applying the function to arguments that are already
+loaded into registers. In a hot loop this extra manipulation can have a large
+impact.
 
 Summary
 -------
@@ -225,49 +228,5 @@ Summary
 #. To tell if your program has undergone lifting you can compare the Core with
    the STG. Or, you may compare STG with and without lifting explicitly enabled.
 
-Testing Exec
-
-.. exec::
-   :context: false
-   :process: haskell
-
-   module Main where
-
-   main :: IO ()
-   main = do
-     let x = fmap (+10) [1..10]
-     print x
-
-
-Great that worked now lets try ``ghci``
-
-
-.. exec::
-   :context: true
-   :process: haskell
-   :with: ghci
-
-   :t "Hello"
-
-and also we can load a package
-
-.. exec::
-   :context: true
-   :process: haskell
-   :with: ghci
-
-   :m + Data.List
-   :t span
-
-and we can also run from cabal target!!
-
-.. exec:: code/lethargy/bench/TooManyClosures.hs
-   :context: true
-   :process: haskell
-   :project_dir: code/lethargy/
-   :with: cabal
-   :args: bench lethargy:tooManyClosures
-
-
 .. [#f1] This program and example comes from :cite:t:`selectiveLambdaLifting`;
          thank you for your labor!:

src/glossary.rst

@@ -5,6 +5,10 @@ Glossary
 
 .. glossary::
 
+   Arity
+
+      The arity of a function is the number of arguments the function must take
+      to conclude to a result.
 
    Boxed : Levity
 
@@ -101,19 +105,35 @@ Glossary
      heavily allocating CAFs can increase memory residency. See
      :cite:t:`jones1992implementing` Section 10.8 for more details.
 
-
    DWARF : Format
 
       DWARF symbols are a widely used and standardized data format used to
       provide source level debugging. For more, see `the official webpage
-      <https://dwarfstd.org/>`_
+      <https://dwarfstd.org/>`_.
+
+   Entry Code
+
+      The entry code for a closure on the heap is the code that will evaluate
+      that closure. There are some nuances and exceptions: For functions the
+      entry code applies the function to its arguments, which the entry code
+      assumes are all present; that is, the entry code assumes all arguments are
+      either loaded into registers or are already on the stack. Should the
+      function be applied to too few arguments or should the function be an
+      :term:`Unknown function` then a generic apply is used. For a :term:`PAP`,
+      there is no entry code. PAPs can only be applied to more arguments using
+      the generic apply functions. Lastly, :term:`Unlifted` Objects cannot be
+      evaluated and thus have no entry code.
 
    Full Laziness transformation : Optimization
 
       A form of :term:`Let Floating` which moves let bindings out of lambda
       abstractions to avoid unnecessary allocation and computation. See
       :cite:t:`peytonjones1997a` Section 7.2.
 
+   Fusion : Optimization
+
+      See :ref:`What is Fusion <canonical-fusion>`.
+
    Info Table : Runtime
 
       Every heap allocated object in the runtime system keeps an information
@@ -123,6 +143,41 @@ Glossary
       <https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/storage/heap-objects#info-tables>`_
       for more details.
 
+   Join Point :  Optimization
+
+      A join point is a place where different execution paths come together or
+      *join*. Consider this example slightly modified from
+      :cite:t:`compilingWithoutCont`:
+
+      .. code-block:: haskell
+
+         let join1 _ = some_large_expression
+             join2 _ = some_other_large_expr
+         in if e1 then (if e2 then join1 () else join2 ())
+                  else (if e3 then join1 () else join2 ())
+
+      In this example, ``join1`` and ``join2`` are join points because the
+      branches described by each if-expression conclude by calling them. Thus,
+      the control flow described by the if-expressions joins at specifically
+      ``join1`` and ``join2``. Join points are an important optimization
+      technique that GHC performs automatically to remove redundant allocations.
+      Had we not wrapped ``some_large_expression`` and ``some_other_large_expr``
+      in a ``let``, then these expressions would be duplicated *and* would be
+      captured in an additionally allocated closure unnecessarily. Join points
+      avoid these problems and are particularly relevant for Stream
+      :term:`Fusion` performance.
+
+    Known Function
+
+      A known function is a function in the STG machine of which GHC statically
+      knows the :term:`Entry Code` pointer and the :term:`Arity` of. This means
+      that the function binding site is statically visible, that is, the
+      function is :term:`Top-Level`, or the function is bound by an enclosing
+      ``let``. With this information the STG machine can use a faster function
+      application procedure because the function pointer does not need to be
+      scrutinized. See also :term:`Unknown Function`.
+
+
    Levity Polymorphism
 
       A kind of polymorphism that abstracts over calling conventions which
@@ -144,6 +199,16 @@ Glossary
       type is a set with three values: ``True``, ``False``, and :math:`\bot`.
       Therefore ``Bool`` is a Lifted type.
 
+   PAP
+
+      A PAP is a partial application. PAPs are heap objects and thus a type of
+      closure that represents a function applied to *too few* arguments. PAPs
+      should never be entered, and are only applied using the generic apply
+      functions in the STG machine. See the file ``rts/Apply.cmm`` in GHC or the
+      `heap object
+      <https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/storage/heap-objects>`_
+      wiki page for more.
+
    Pinned : Memory
 
      Pinned memory is memory that is guaranteed to not be moved by GHC's garbage
@@ -162,6 +227,11 @@ Glossary
       provides Haskell's laziness. See :cite:t:`SpinelessTaglessGMachine`
       Section 3.1.2 for more details.
 
+   Top-level binding
+
+      A top level binding is any binding that exists in the most outer-most or
+      global scope of the program.
+
    Unboxed : Levity
 
       An UnBoxed value is a value that is represented by the value itself.
@@ -172,6 +242,18 @@ Glossary
       An Unlifted type is a type where :math:`\bot` *is not* an element of that
       type. See :term:`Levity Polymorphism` and :term:`Lifted` types for more.
 
+   Unknown function
+
+      An unknown function is a function in the STG machine whose :term:`Entry
+      Code` pointer and :term:`Arity` are not statically known by GHC. Unknown
+      functions require GHC to generate code that first scrutinizes the function
+      pointer to determine its arity and then dispatch to the normal function
+      call handling procedures. This in known has a generic apply in the STG
+      machine and is slower (due to needing to scrutinize the function) than a
+      :term:`Known function`. See :cite:t:`fastCurry` for more details on STG
+      calling conventions.
+
+
    WHNF : Normal Forms
 
       An expression is in *weak head normal form* if it has been evaluated to