[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