On Sat, Mar 29, 2008 at 2:51 PM, Ned Batchelder <report@bugs.python.org> wrote:
>
>  Ned Batchelder <nedbat@users.sourceforge.net> added the comment:
>
>  I am measuring the code coverage of a set of tests, and one of my lines
>  is being marked as not executed.  This is not the fault of the tests,
>  because in fact, without the optimization, the line would be executed.
>  Conceptually, the line has been executed (the loop is restarted, rather
>  than execution continuing).
>

.. but the continue statement on line 5 is NOT executed in x == True
case.   Note that without optimization, the if statement + the
continue line translate to

  3          19 LOAD_FAST                0 (x)
             22 JUMP_IF_FALSE            4 (to 29)
             25 POP_TOP

  4          26 JUMP_FORWARD             1 (to 30)
        >>   29 POP_TOP

  5     >>   30 JUMP_ABSOLUTE           13

where the second jump is to the continue statement.  Peephole
optimizer recognizes that the jump target is an unconditional jump and
changes the code to jump directly to the final target bypassing the
continue line.  The optimized code is

 3          19 LOAD_FAST                0 (x)
             22 JUMP_IF_FALSE            4 (to 29)
             25 POP_TOP

  4          26 JUMP_ABSOLUTE           13
        >>   29 POP_TOP

  5          30 JUMP_ABSOLUTE           13

If x is true, line five is NOT executed.

>  I don't know what the solution to this is.  Some options include fixing
>  the line tracing code to somehow indicate that the continue was
>  executed; or providing a way to disable peephole optimization for times
>  when accurate execution tracing is more important than speed.
>

I think it is a good idea to provide a way to disable peephole
optimizer. In fact, I recently proposed exactly that in msg64638.   My
only problem is that I would like to follow gcc tradition and make -O
option take an optional  numeric  argument with 0 meaning no
optimization and increasingly aggressive optimization as the argument
increases.  Unfortunately -O0 will be confusingly similar to -OO.
Since -OO is not really optimization, but rather "strip" option, it
should probably migrate to -s or something.  In any case, such drastic
changes to command line options are not acceptable for 2.x, but maybe
possible for 3.0.

I can easily implement -N (No optimization) or -g  (debug) option that
will disable the peephole optimizer if there is support for such
feature.