[pypy-commit] pypy core-only-tracing: (antocuni, arigo, romain) complain if a graph is marked as access_direct but not core, because in this case we would have a wrong behaviour when tracing in core-only mode

antocuni noreply at buildbot.pypy.org
Fri Jan 20 15:35:12 CET 2012


Author: Antonio Cuni <anto.cuni at gmail.com>
Branch: core-only-tracing
Changeset: r51528:da475d18764e
Date: 2012-01-20 12:11 +0100
http://bitbucket.org/pypy/pypy/changeset/da475d18764e/

Log:	(antocuni, arigo, romain) complain if a graph is marked as
	access_direct but not core, because in this case we would have a
	wrong behaviour when tracing in core-only mode

diff --git a/pypy/jit/codewriter/policy.py b/pypy/jit/codewriter/policy.py
--- a/pypy/jit/codewriter/policy.py
+++ b/pypy/jit/codewriter/policy.py
@@ -76,19 +76,22 @@
         if res and contains_loop:
             self.unsafe_loopy_graphs.add(graph)
         res = res and not contains_loop
-        if (see_function and not res and
-            getattr(graph, "access_directly", False)):
-            # This happens when we have a function which has an argument with
-            # the access_directly flag, and the annotator has determined we will
-            # see the function. (See
-            # pypy/annotation/specialize.py:default_specialize) However,
-            # look_inside_graph just decided that we will not see it. (It has a
-            # loop or unsupported variables.) If we return False, the call will
-            # be turned into a residual call, but the graph is access_directly!
-            # If such a function is called and accesses a virtualizable, the JIT
-            # will not notice, and the virtualizable will fall out of sync. So,
-            # we fail loudly now.
-            raise ValueError("access_directly on a function which we don't see %s" % graph)
+        if getattr(graph, "access_directly", False):
+            if (see_function and not res):
+                # This happens when we have a function which has an argument with
+                # the access_directly flag, and the annotator has determined we will
+                # see the function. (See
+                # pypy/annotation/specialize.py:default_specialize) However,
+                # look_inside_graph just decided that we will not see it. (It has a
+                # loop or unsupported variables.) If we return False, the call will
+                # be turned into a residual call, but the graph is access_directly!
+                # If such a function is called and accesses a virtualizable, the JIT
+                # will not notice, and the virtualizable will fall out of sync. So,
+                # we fail loudly now.
+                raise ValueError("access_directly on a function which we don't see %s" % graph)
+            if not self.is_core_graph(graph):
+                # the same comment as above applies when we run in core-only tracing mode
+                raise ValueError("access_directly on a function which is not core: %s" % graph)
         return res
 
 def contains_unsupported_variable_type(graph, supports_floats,
diff --git a/pypy/jit/codewriter/test/test_policy.py b/pypy/jit/codewriter/test/test_policy.py
--- a/pypy/jit/codewriter/test/test_policy.py
+++ b/pypy/jit/codewriter/test/test_policy.py
@@ -130,3 +130,23 @@
     h_graph = rtyper.annotator.translator.graphs[1]
     assert h_graph.func is h
     py.test.raises(ValueError, JitPolicy().look_inside_graph, h_graph)
+
+
+def test_access_directly_but_not_core():
+    class MyPolicy(JitPolicy):
+        def is_core_graph(self, graph):
+            assert graph.name.startswith('h__AccessDirect')
+            return False
+    
+    class X:
+        _virtualizable2_ = ["a"]
+    def h(x, y):
+        return x.a + y
+    def f(y):
+        x = jit.hint(X(), access_directly=True)
+        x.a = 4
+        h(x, y)
+    rtyper = support.annotate(f, [3])
+    h_graph = rtyper.annotator.translator.graphs[1]
+    assert h_graph.func is h
+    py.test.raises(ValueError, MyPolicy().look_inside_graph, h_graph)


More information about the pypy-commit mailing list