[pypy-svn] r35692 - pypy/dist/pypy/doc

arigo at codespeak.net arigo at codespeak.net
Wed Dec 13 19:35:42 CET 2006


Author: arigo
Date: Wed Dec 13 19:35:39 2006
New Revision: 35692

Modified:
   pypy/dist/pypy/doc/draft-jit-outline.txt
Log:
BTA and hints.


Modified: pypy/dist/pypy/doc/draft-jit-outline.txt
==============================================================================
--- pypy/dist/pypy/doc/draft-jit-outline.txt	(original)
+++ pypy/dist/pypy/doc/draft-jit-outline.txt	Wed Dec 13 19:35:39 2006
@@ -146,7 +146,98 @@
 Binding-time analysis
 =========================================
 
-Hint annotator and hint(concrete=True)...
+PyPy performs binding-time analysis of the source RPython_ program after
+it has been turned to `low-level graphs`_, i.e. at the level at which
+operations manipulate `pointer-and-structures-like objects`_.
+
+The binding-time analyzer of our translation toolchain is based on the
+same type inference engine that is used on the source RPython program,
+the annotator_.  In this mode, it is called the *hint-annotator*; it
+operates over input graphs that are already low-level instead of
+RPython-level, and propagates annotations that do not track types but
+value dependencies and manually-provided binding time hints.
+
+Hints
+----------------------------------
+
+Our goal in designing our approach to binding-time analysis was to
+minimize the number of explicit hints that the user must provide in the
+source of the RPython program.  This minimalism was not pushed to
+extremes, though, to keep the hint-annotator reasonably simple.
+
+The driving idea was that hints should be need-oriented.  In a program
+like an interpreter, there are a few clear places where it would be
+beneficial for a given value to be known at compile-time, i.e. green.
+This is where we require the hints to be added.
+
+The normal process of the hint-annotator is to propagate the binding
+time (i.e. color) of the variables using the following kind of rules:
+
+* For a foldable operation (i.e. one without side effect and which
+  depends only on its argument's value), if all arguments are green,
+  then the result can be green too.
+
+* Non-foldable operations always produce a red result.
+
+* At join points, where multiple possible values (depending on control
+  flow) are meeting into a fresh variable, if any incoming value comes
+  from a red variable, the result is red.  Otherwise, the color of the
+  result might be green.  We do not make it eagerly green, because of
+  the control flow dependency: the residual function is basically a
+  constant-folded copy of the source function, so it might retain some
+  of the same control flow.  The value that needs to be stored in the
+  fresh join variable thus depends on which branches are taken in the
+  residual graph.
+
+The hint-annotator assumes that all variables are red by default (with
+the exception of constants, which are always green).  It then propagates
+annotations that record dependency information.  When encountering the
+user-provided hints, the dependency information is used to make some
+variables green.  (Technically, the color itself is not part of the
+annotations propagated by the annotator.)  All hints are in the form of
+an operation ``hint(v1, someflag=True)`` which semantically just returns
+its first argument unmodified.  The three kinds of hints that are useful
+in practice are:
+
+``v2 = hint(v1, concrete=True)``
+    This is interpreted by the hint-annotator as a request for both
+    ``v1`` and ``v2`` to be green.  It is used in places where the
+    programmer considers the knowledge of the value to be essential.
+    This hint has a *global* effect on the binding times: it means that
+    not only ``v1`` but all the values that ``v1`` depends on -
+    recursively - are forced to be green.  Typically, it can only be
+    applied on values that directly depend on some input arguments,
+    making these input arguments green.  The hint-annotator complains if
+    the dependencies of ``v1`` include a value that cannot be green,
+    like a value read out of a field out of a non-immutable structure.
+
+    The color of the result ``v2`` is green as well.  Unlike ``v1``, all
+    further operations involving ``v2`` are checked to not meet any red
+    variable (i.e. ``v2`` is eagerly and recursively propagated, while
+    ``v1`` is only green and may be involved in further operations that
+    will produce red results).
+
+``v2 = hint(v1, promote=True)``
+    This hint is a *local* request for ``v2`` to be green.  Unlike the
+    previous hint, this one has no effect on the color of ``v1`` (which
+    is typically red - the hint has no effect otherwise).
+
+    Note that in classical approaches to partial evalution, it is not
+    possible to copy a red value into a green one.  The implementation
+    of such an operation ("promotion") is only possible in a
+    "just-in-time" approach that only Psyco_ implemented so far (to the
+    best of our knowledge).  Our hint is a direct generalization of the
+    latter.
+
+``v2 = hint(v1, variable=True)``
+    Force ``v2`` to be red, even if ``v1`` is green.
+
+A program using promotion also need to contain a "global merge point"
+hint; this has no effect on the hint-annotator and is described in the
+section about promotion_.
+
+
+
 
 calls...
 
@@ -189,10 +280,12 @@
 
 ...
 
+.. _promotion:
+
 Promotion and global merges
 -----------------------------
 
-...
+...global merge point...
 
 Partial data
 -------------



More information about the Pypy-commit mailing list