On Fri, Mar 30, 2012 at 1:58 AM, Hakan Ardo <[email protected]> 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 <[email protected]> > wrote: > > Author: Alex Gaynor <[email protected]> > > 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 > > [email protected] > > http://mail.python.org/mailman/listinfo/pypy-commit > > > > -- > Håkan Ardö > _______________________________________________ > pypy-dev mailing list > [email protected] > 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
_______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
