On Sun, Nov 8, 2015 at 9:52 AM, Armin Rigo <ar...@tunes.org> wrote: > > Ah, that's a good plan too. It needs to have a way to record what we > saw during tracing (preferably not in some huge dict), and we decided > long ago that the optimizer should not essentially look at the content > of boxes (apart to guide some optimizations). For example, CALL_PURE > uses a big dict. The problem is that such a dict would be much bigger > for all GETFIELD_PURE. >
Why not store the observed results on the resops (maybe using some new OpWithObservedResult mixin to not get an extra field on all of them)? > > I'm still going with checking the gctype of the object. It should > work in the same cases (and theoretically more but well). > Yes, makes sens. Another thing that strikes me is that those crazy cases does probably not benefit much from unrolling, and the only result of unrolling them might be to duplicate a lot of guards, which leads to more tracing of bridges. Maybe it would be beneficial to compare the constant inputargs of the peeled loop with the observed inputargs of the preamble and if they don't match (differ enough?) skip unrolling for that loop. Alternatively demote the non-matching constants non-constants (as they are obviously not loop invariant constants) to make the peeled loop a more general target for bridges to jump directly to. -- Håkan Ardö
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
