[issue6250] Python compiles dead code

Martin v. Löwis added the comment: I'm also happy with rejecting the patch, and agree with everything that has been brought up against it: from an end-user point of view, there is a negligible-if-any benefit (e.g. if you want to speed up importing, try to reduce the number of stat() calls instea

[issue6250] Python compiles dead code

Raymond Hettinger added the comment: Martin, am transferring this to you for adjudication. I'm -0 on the patch. On the plus side, the code is well thought-out and reasonably well tested. On the minus side, it complexifies the compiler in a way that may make it more difficult to maintain. The

[issue6250] Python compiles dead code

James Abbatiello added the comment: Raymond, I've updated peephole.c to allow code to terminate with any of RETURN_VALUE, END_FINALLY or RAISE_VARARGS [0-3]. I also added tests to test_peepholer.py to make sure the peepholer still works in these cases. -- _

[issue6250] Python compiles dead code

Raymond Hettinger added the comment: James, the peepholer currently assumes that codestrings terminate with RETURN_VALUE. Is this assumption invalidated by your code? -- ___ Python tracker

[issue6250] Python compiles dead code

James Abbatiello added the comment: I should add that the patch doesn't only address dead user-code. It also eliminates code that the compiler generates itself but that would be unreachable at runtime. Consider the following function: def foo(x): if x: raise Something else: raise

[issue6250] Python compiles dead code

Raymond Hettinger added the comment: Are you looking for dead code detection (like a lint utility) or automatic dead code removal (modified code)? -- ___ Python tracker ___ _

[issue6250] Python compiles dead code

Collin Winter added the comment: Standalone bytecode-modifying tools almost never check that they're outputting correct bytecode. http://code.activestate.com/recipes/277940/ makes no attempt to check what version of Python it's running under; running it under Unladen Swallow 2009Q1 would have pr

[issue6250] Python compiles dead code

Raymond Hettinger added the comment: I'm curious to whether this needs to be embedded in the compiler or whether a standalone tool can be offered. See http://code.activestate.com/recipes/277940/ for an example of processing the bytecodes directly. FWIW, deadcode can already be detected by some

[issue6250] Python compiles dead code

Raymond Hettinger added the comment: It looks like the patch is extensive and well thought out. I look forward to going through it in detail. -- ___ Python tracker ___ _

[issue6250] Python compiles dead code

Collin Winter added the comment: As another data point, Unladen Swallow had to take explicit steps to deal with this dead code when compiling bytecode to machine code. Since Python's compiler isn't smart enough to ignore code following a "return" or "raise" in the same suite, support for that ha

[issue6250] Python compiles dead code

Raymond Hettinger added the comment: We've rejected dead-code elimination in the past (too much effort for nearly zero benefit). Will take a look at your patch though. -- assignee: -> rhettinger nosy: +rhettinger priority: -> low type: -> performance ___

[issue6250] Python compiles dead code

New submission from James Abbatiello : Python currently emits bytecode for code that is unreachable (e.g. following a return statement). This doesn't hurt anything but it takes up space doing nothing. This patch attempts to avoid generating any bytecode in this situation. There's an optional w