On 5/22/14 1:16 PM, Nathaniel Smith wrote:
On Thu, May 22, 2014 at 4:32 PM, Ned Batchelder <ned@nedbatchelder.com> wrote:
It seems to me that Ned has revealed a bug in the peephole optimizer. It zapped an entire source line's worth of bytecode, but failed to delete the relevant entry in the line number table of the resulting code object. If I had my druthers, that would be the change I'd prefer. I think it is the nature of optimization that it will destroy useful information. I don't think it will always be possible to retain enough back-mapping that the optimized code can be understood as if it had not been optimized. For example, the debug issue would still be present: if you run
On 5/22/14 9:49 AM, Skip Montanaro wrote: pdb and set a breakpoint on the "continue" line, it will never be hit. Even if the optimizer cleaned up after itself perfectly (in fact, especially so), that breakpoint will still not be hit. You simply cannot reason about optimized code without having to mentally understand the transformations that have been applied. In this particular case, the back-mapping problem is pretty minor. IIUC the optimization is that if we have (abusing BASIC notation)
10 GOTO 20 20 GOTO 30 30 ...
then in fact the operations at lines 10 and 20 are, from the point of view of the rest of the program, indivisible -- every time you execute 10 you also execute 20, there is no way to tell from outside whether we paused in betwen executing 10 and 20, etc. Effectively we just have a single uber-instruction that does both:
(10, 20) GOTO 30 30 ...
So from the coverage point of view, just marking line 20 as covered every time line 10 is executed is the Right Thing To Do. From the debugging point of view, a breakpoint set at line 20 should just trip whenever line 10 is executed -- it's not like there's any way to tell whether we're "half way through" the jump sequence or not. It's a pretty solid abstraction.
-n
You've used the word "just" three times, glossing over the fact that we have no facility for marking statements as an uber instruction, and you've made no proposal for how it might work. Even if we build (and test!) a way to do that, it only covers this particular kind of oddity with optimized code. --Ned.