[pypy-dev] [pypy-commit] pypy dynamic-specialized-tuple: kill an assert that doesn't hold now.

[Alex Gaynor]

On Fri, Mar 30, 2012 at 1:58 AM, Hakan Ardo <hakan at debian.org> wrote:

> Hi,
> if the descr can change and assumptions are made about it you'll need
> to add it to virtualstate.NotVirtualStateInfo and check it in
> generalization_of and _generate_guards. Otherwise if a peeled loop
> becomes specialized to some specific descr and that descr is changed
> on a bridge, the bridge will jump to the peeled loop, but it has to
> jump to the preamble.
>
> On Fri, Mar 30, 2012 at 4:00 AM, alex_gaynor <noreply at buildbot.pypy.org>
> wrote:
> > Author: Alex Gaynor <alex.gaynor at gmail.com>
> > Branch: dynamic-specialized-tuple
> > Changeset: r54088:5b813268023d
> > Date: 2012-03-29 21:59 -0400
> > http://bitbucket.org/pypy/pypy/changeset/5b813268023d/
> >
> > Log:    kill an assert that doesn't hold now.
> >
> > diff --git a/pypy/jit/metainterp/optimizeopt/optimizer.py
> b/pypy/jit/metainterp/optimizeopt/optimizer.py
> > --- a/pypy/jit/metainterp/optimizeopt/optimizer.py
> > +++ b/pypy/jit/metainterp/optimizeopt/optimizer.py
> > @@ -59,7 +59,6 @@
> >     def make_len_gt(self, mode, descr, val):
> >         if self.lenbound:
> >             assert self.lenbound.mode == mode
> > -            assert self.lenbound.descr == descr
> >             self.lenbound.bound.make_gt(IntBound(val, val))
> >         else:
> >             self.lenbound = LenBound(mode, descr, IntLowerBound(val + 1))
> > _______________________________________________
> > pypy-commit mailing list
> > pypy-commit at python.org
> > http://mail.python.org/mailman/listinfo/pypy-commit
>
>
>
> --
> Håkan Ardö
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>

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:

p0 = new(<untyped storage>)
setfield_gc(p0, ConstPtr("io"), <FieldDescr shape>)
setarrayitem_gc(p0, 0, i0, <ArrayDescr int>)
setarrayitem_gc(p0, 1, p1, <ArrayDescr ptr>)
finish(p0)

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.

Alex
-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20120330/cb56853f/attachment.html>