Hi Hakan, On 12/03/11 19:25, Hakan Ardo wrote: > 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.
ok, that's clear. So, hopefully this particular example looks a bit bad, but in general it should not be an issue. It'd be nice to have a way to check this thesis, but I agree that it's a bit hard. > 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). so, if I understand correctly, this is what happens: 1. we trace, optimize and compile loop A 2. after a while, we trace, optimize a compile a bridge B which then jumps back to A; by chance, the bridge looks the same as the loop Am I right? > 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... I just did a quick check because I'm in a hurry, but from what I see we get three actual *loops*, not bridges. ciao, Anto _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev