Re: [pypy-dev] [pypy-commit] pypy dynamic-specialized-tuple: kill an assert that doesn't hold now.
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@buildbot.pypy.org> wrote:
-- Håkan Ardö
On Fri, Mar 30, 2012 at 1:58 AM, Hakan Ardo <hakan@debian.org> wrote:
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
On Fri, Mar 30, 2012 at 2:49 PM, Alex Gaynor <alex.gaynor@gmail.com> wrote:
That part might be fine. In this case the descr depends is not realy changing it just depends on the constant index. The assert could probably be relaxed to allow that. But what would traces reading values from the tuple look like. In cases where the tuple may conatin different types or if the index is not constant? Say something like this: sa = 0 a = (1, 2.0) while sa < 3000: sa += a[0] + a[1] if sa > 1500: a = (a[1], a[0]) -- Håkan Ardö
On Fri, Mar 30, 2012 at 9:15 AM, Hakan Ardo <hakan@debian.org> wrote:
My idea is approximately you promote the shape whenever the index of a read is constant. Otherwise you produce a read on the shape, and a guard about the type. 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
On Fri, Mar 30, 2012 at 3:18 PM, Alex Gaynor <alex.gaynor@gmail.com> wrote:
But you would still need a guard about the type, right?
Otherwise you produce a read on the shape, and a guard about the type.
These guards we'll need to be added to the virtualstate in the same way as guards regarding the length of an array is treated. If those guards are always explicit guards that should be simple. But if they are implicit it might be tricky. By implicit I mean things like after getarrayitem_gc(p0, 7) we will assume that the length of p0 is at least 8. The alternative is to not allow this kind of information to propagate across loop boundaries, like we do with unerased pointers. In that case the "guards" about the types are implied by the surrounding rpython code and there is no way for the jit to extract the information.
-- Håkan Ardö
On Fri, Mar 30, 2012 at 1:58 AM, Hakan Ardo <hakan@debian.org> wrote:
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
On Fri, Mar 30, 2012 at 2:49 PM, Alex Gaynor <alex.gaynor@gmail.com> wrote:
That part might be fine. In this case the descr depends is not realy changing it just depends on the constant index. The assert could probably be relaxed to allow that. But what would traces reading values from the tuple look like. In cases where the tuple may conatin different types or if the index is not constant? Say something like this: sa = 0 a = (1, 2.0) while sa < 3000: sa += a[0] + a[1] if sa > 1500: a = (a[1], a[0]) -- Håkan Ardö
On Fri, Mar 30, 2012 at 9:15 AM, Hakan Ardo <hakan@debian.org> wrote:
My idea is approximately you promote the shape whenever the index of a read is constant. Otherwise you produce a read on the shape, and a guard about the type. 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
On Fri, Mar 30, 2012 at 3:18 PM, Alex Gaynor <alex.gaynor@gmail.com> wrote:
But you would still need a guard about the type, right?
Otherwise you produce a read on the shape, and a guard about the type.
These guards we'll need to be added to the virtualstate in the same way as guards regarding the length of an array is treated. If those guards are always explicit guards that should be simple. But if they are implicit it might be tricky. By implicit I mean things like after getarrayitem_gc(p0, 7) we will assume that the length of p0 is at least 8. The alternative is to not allow this kind of information to propagate across loop boundaries, like we do with unerased pointers. In that case the "guards" about the types are implied by the surrounding rpython code and there is no way for the jit to extract the information.
-- Håkan Ardö
participants (2)
-
Alex Gaynor -
Hakan Ardo