[pypy-svn] r69638 - pypy/branch/virtual-forcing/pypy/jit/metainterp/doc

[arigo at codespeak.net]

Author: arigo
Date: Wed Nov 25 17:20:17 2009
New Revision: 69638

Removed:
   pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/linking.txt
   pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/matching_rules.txt
   pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/virtualizables.txt
Modified:
   pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/jitpl5.txt
   pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/loop.txt
Log:
Delete and simplify the "explanations" here.  Should be killed at some
point, and written down as real documentation.


Modified: pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/jitpl5.txt
==============================================================================
--- pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/jitpl5.txt	(original)
+++ pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/jitpl5.txt	Wed Nov 25 17:20:17 2009
@@ -78,16 +78,11 @@
 matches the real data -- but this is delicate because of the
 non-escaping flag.
 
-Instead, this is done by doing tracing from the start of the loop again.
-At the end, we don't do perfect specialization (for now), but simply
-check that the already-computed specialization still applies, and then
-jump to the already-compiled loop.  (If it does not match, for now we
-just cancel everything.)
-
-If the loop is not only executed but *entered* often enough, then after
-this tracing, we generate a second copy of the loop (a "bridge") that
-starts with all variables unspecialized, and ends with a jump to the
-real loop.  From this point on, we can just jump directly to the bridge
+Instead, this is done by "entry bridges": we do tracing from
+the start of the loop again, and at the end, we try to compile
+the recorded trace as a "bridge" that comes from the
+interpreter (i.e. with no virtuals at all) and goes to the old
+loop.  Later on, we can just jump directly to the entry bridge
 from the JUMP_ABSOLUTE bytecode.
 
 
@@ -105,10 +100,7 @@
 take the set of live values and put them back into boxes, and proceed
 with tracing for the rest of the loop.
 
-For now, we just check at the end of the loop that it matches the
-already-computed specialization.  If not, we cancel creating the
-compiled version of it (and mark the guard so that future failures
-always fall back to interpretation).  To do this, when we created the
-original loop, at every guard, we needed to record the set of live
-values (mostly in which register or stack location they are) as well as
-an "escaped-so-far" flag for each pointer.
+At the end of the loop, we check that it matches an already-computed
+specialization.  If not, we go on tracing.  This might unroll the loop
+once.  (Note that there is a global limit on the length of the recorded
+trace, to avoid tracing forever.)

Modified: pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/loop.txt
==============================================================================
--- pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/loop.txt	(original)
+++ pypy/branch/virtual-forcing/pypy/jit/metainterp/doc/loop.txt	Wed Nov 25 17:20:17 2009
@@ -36,32 +36,11 @@
 
     .       VirtualSpec(cls, name1=spec1, ...)
                     |
-         VirtualizableSpec(cls, name1=spec1, ...)
-                    |
-              FixedClassSpec(cls)
-                    |
                  NotSpec
 
-For (a simplified) example, ``VirtualizableSpec(PyFrame, x =
-VirtualSpec(W_IntObject, value = NotSpec))`` describes the virtualizable
-frame for a loop in which the only used variable is ``x``, which is a
-virtual ``W_IntObject``.
-
-The intersection rules are:
-
-* the intersection of two ``VirtualSpec`` of the same ``cls`` is a
-  further ``VirtualSpec``, and we proceed with the intersection of
-  each field.
-
-* the intersection of two ``VirtualizableSpec`` of the same ``cls`` is
-  like the previous case, except that some names may be omitted
-  completely from a given ``VirtualizableSpec``; in the case a name is
-  present in only one of the ``VirtualizableSpec``, we just keep it
-  unmodified in the intersection.
-
-* in other cases, the result is ``FixedClassSpec`` if the two specnodes
-  have the same class, or ``NotSpec`` if any is a ``NotSpec`` or if the
-  two classes differ.
+For example, ``VirtualSpec(W_IntObject, value = NotSpec))`` describes a
+variable which is a virtual ``W_IntObject``, containing a value that is
+a real integer.
 
 
 Overall Approach