Ned Batchelder <n...@nedbatchelder.com> added the comment:
> PEP 626 states that *all* executed code gets traced. Yes, but reading the PEP now, it's not clear what "executed" means. Do we mean "conceptually executed", or, "executed as compiled by the optimizing compiler"? > In fact this NOP can be removed by rewriting the bytecode to: That change looks both difficult and confusing. If we want to keep an "if 0:" line in the bytecode, NOP is the best way to do it. > But why remove it? It is in the source code. I think the reason you are keeping it now isn't because it is in the source code. Lines after returns are in the source code, but are now removed because they aren't in the path of execution. "if 0:" is in the path of execution, so now you are keeping it. (I guess: I don't mean to put words in your mouth.) As I mentioned, this is a change from previous versions, which removed the "if 0:" as uninteresting code. > Do we want tracing and profiling to depend on what transformations the > optimizer does or does not make? Tracing has long depended on the optimizer's transformations. When the optimizer removes a jump to a jump, the tracing never sees the removed intermediate jump. The reason I am writing these bug reports is because coverage.py tries to track CPython's optimizations. Coverage.py "knows" that "if 0:" lines won't appear in the trace, because previous versions removed them. Unfortunately, it's not possible to make the match perfect. See bug 2506 for the original debate about this point. As it stands now, CPython will keep statements in the byte code that are "conceptually" executed, but because of optimization, are never executed. This creates a gap between the developer's mental model and the data produced by tools. I can adjust coverage.py to reflect the decision either way from this bug report. Mostly I raise the issues to point out differences and to get a clear decision about whether it's desired behavior. > If the runtime does speculatively inlining, should it change what code is to > be traced? I hope this is purely hypothetical. If CPython gets to that point we are going to have to revisit what kinds of controls there are to disable optimizations. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42693> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
