<br><br><div class="gmail_quote">On Fri, Mar 30, 2012 at 1:58 AM, Hakan Ardo <span dir="ltr"><<a href="mailto:hakan@debian.org">hakan@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
if the descr can change and assumptions are made about it you'll need<br>
to add it to virtualstate.NotVirtualStateInfo and check it in<br>
generalization_of and _generate_guards. Otherwise if a peeled loop<br>
becomes specialized to some specific descr and that descr is changed<br>
on a bridge, the bridge will jump to the peeled loop, but it has to<br>
jump to the preamble.<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Mar 30, 2012 at 4:00 AM, alex_gaynor <<a href="mailto:noreply@buildbot.pypy.org">noreply@buildbot.pypy.org</a>> wrote:<br>
> Author: Alex Gaynor <<a href="mailto:alex.gaynor@gmail.com">alex.gaynor@gmail.com</a>><br>
> Branch: dynamic-specialized-tuple<br>
> Changeset: r54088:5b813268023d<br>
> Date: 2012-03-29 21:59 -0400<br>
> <a href="http://bitbucket.org/pypy/pypy/changeset/5b813268023d/" target="_blank">http://bitbucket.org/pypy/pypy/changeset/5b813268023d/</a><br>
><br>
> Log: kill an assert that doesn't hold now.<br>
><br>
> diff --git a/pypy/jit/metainterp/optimizeopt/optimizer.py b/pypy/jit/metainterp/optimizeopt/optimizer.py<br>
> --- a/pypy/jit/metainterp/optimizeopt/optimizer.py<br>
> +++ b/pypy/jit/metainterp/optimizeopt/optimizer.py<br>
> @@ -59,7 +59,6 @@<br>
> def make_len_gt(self, mode, descr, val):<br>
> if self.lenbound:<br>
> assert self.lenbound.mode == mode<br>
> - assert self.lenbound.descr == descr<br>
> self.lenbound.bound.make_gt(IntBound(val, val))<br>
> else:<br>
> self.lenbound = LenBound(mode, descr, IntLowerBound(val + 1))<br>
> _______________________________________________<br>
> pypy-commit mailing list<br>
> <a href="mailto:pypy-commit@python.org">pypy-commit@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/pypy-commit" target="_blank">http://mail.python.org/mailman/listinfo/pypy-commit</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Håkan Ardö<br>
_______________________________________________<br>
pypy-dev mailing list<br>
<a href="mailto:pypy-dev@python.org">pypy-dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/pypy-dev" target="_blank">http://mail.python.org/mailman/listinfo/pypy-dev</a><br>
</font></span></blockquote></div><br>I'm a bit concerned that this branch may be breaking too many assumptions in the JIT with the current approach. The idea of this branch is to dynamically specialize the shape of a tuple's memory, to store unboxed objects. Based on the current approach (storing all data in an array of integers) you get traces that look like:<div>
<br></div><div>p0 = new(<untyped storage>)</div><div>setfield_gc(p0, ConstPtr("io"), <FieldDescr shape>)</div><div>setarrayitem_gc(p0, 0, i0, <ArrayDescr int>)</div><div>setarrayitem_gc(p0, 1, p1, <ArrayDescr ptr>)</div>
<div>finish(p0)</div><div><div><br></div><div>This is a trace for allocating a tuple like (int1, ptr1) and returning it. Do you think a trace like this breaks too many assumptions in the JIT, and if so, how can we go about making the JIT work with this.</div>
<div><br></div><div>Alex</div>-- <br>"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)<br>"The people's good is the highest law." -- Cicero<br>
<br>
</div>