Yes, this is probably the VirtualState checking. It will retrace a loop whenever the VirtualState at the end of a bridge differs from the VirtualState at the beginning of the compiled trace (any of the compiled traces). This might indeed produce an identical trace if we are unlucky, but the idea is that this should only happen rarely.
This is because the VirtualState at the beginning of a trace is the state of all the OptValue of the inputargs produced during the optimization of the trace. This does not have to be the most general state for which the trace is usable (which would be hard to calculate I'm afraid). A few cases that would (most likely) result in identical traces are salvaged in NotVirtualInfo._generate_guards by producing some extra gurads at the end of a bridge to make the VirtualState there match the VirtualState of a compiled trace. This is however only done if the guards would (most likely) not fail for the traced iteration. I'll look into what's happening in this particular test... On Thu, Mar 10, 2011 at 6:22 PM, Antonio Cuni <anto.c...@gmail.com> wrote: > On 10/03/11 16:21, Antonio Cuni wrote: > >> I did a bit of manual binary search and discovered that the test started >> failing between r42273:b8bb5d085684 and r42305:3fe93dd500bd. Looking at the >> commit, it seems that the only one relevant to the problem is >> r42305:3fe93dd500bd, i.e. the merging of jit-virtual_state. > > I confirm that the problem is the merging of jit-virtual_state: I just tried > the revision just before the merge, and the test passes. > > ciao, > Anto > -- Håkan Ardö _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev