[Python-ideas] Disable all peephole optimizations

[Jonas Wielicki]

On 21.05.2014 14:13, Steven D'Aprano wrote:
> On Wed, May 21, 2014 at 07:05:49AM -0400, Ned Batchelder wrote:
>> ** The problem
>>
>> A long-standing problem with CPython is that the peephole optimizer 
>> cannot be completely disabled.  Normally, peephole optimization is a 
>> good thing, it improves execution speed.  But in some situations, like 
>> coverage testing, it's more important to be able to reason about the 
>> code's execution.  I propose that we add a way to completely disable the 
>> optimizer.
> 
> I'm not sure whether this is an argument for or against your proposal, 
> but the continue statement shown below is *not* dead code and should not 
> be optimized out. The assert fails if you remove the continue statement.
> 
> I don't have 3.4 on this machine to test with, but using 3.3, I can see 
> no evidence that `continue` is optimized away. 

The logical continue is still there -- what happens is that the
optimizer rewrites the `else` jump at the preceding `if` condition,
which would normally point at the `continue` statement, to the beginning
of the loop, because it would be a jump (to the continue) to a jump (to
the for loop header).

Thus, the actual continue statement is not reached, but logically the
code does the same, because the only way continue would have been
reached was transformed to a continue itself.

> Later in your post, you 
> say:
> 
>> It's true: the
>> byte code for that statement [the continue] is not executed, because 
>> the peephole optimizer has removed the jump to the jump.
> 
> But that cannot be true, because if it were, the assertion would 
> fail. Here's your code again:
> 
> 
>> To demonstrate the problem, here is continue.py:
>>
>>    a = b = c = 0
>>    for n in range(100):
>>         if n % 2:
>>             if n % 4:
>>                 a += 1
>>             continue
>>         else:
>>             b += 1
>>         c += 1
>>    assert a == 50 and b == 50 and c == 50
> 
> If the continue were not executed, c would equal 100 and the assertion 
> would fail. Have I misunderstood something?
> 
> (By the way, as given, your indents are inconsistent: some are 4 spaces 
> and some are 5.)
> 
>