Repository navigation
Python3.8 optimizes away a "while" line #79069
Description
| BPO | 34888 |
|---|---|
| Nosy | @vstinner, @nedbat, @benjaminp, @serhiy-storchaka, @1st1, @iritkatriel |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2018-10-04.00:00:40.974>
labels = ['interpreter-core', '3.8']
title = 'Python3.8 optimizes away a "while" line'
updated_at = <Date 2022-01-28.19:12:25.887>
user = 'https://github.com/nedbat'bugs.python.org fields:
activity = <Date 2022-01-28.19:12:25.887>
actor = 'iritkatriel'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2018-10-04.00:00:40.974>
creator = 'nedbat'
dependencies = []
files = []
hgrepos = []
issue_num = 34888
keywords = []
message_count = 7.0
messages = ['327019', '327026', '327027', '327028', '327029', '327031', '412026']
nosy_count = 6.0
nosy_names = ['vstinner', 'nedbat', 'benjamin.peterson', 'serhiy.storchaka', 'yselivanov', 'iritkatriel']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue34888'
versions = ['Python 3.8']
Activity
nedbat commentedon Oct 4, 2018
Looks like the optimizer is getting more aggressive. Line 2 (the constant while) no longer even appears in the bytecode:
$ cat -n whiletrue.py 1 a = 1 2 while 1: 3 print(a) 4 b = 4 $ python3.7 -m dis < whiletrue.py 1 0 LOAD_CONST 0 (1) 2 STORE_NAME 0 (a)2 4 SETUP_LOOP 12 (to 18)
3 >> 6 LOAD_NAME 1 (print)
8 LOAD_NAME 0 (a)
10 CALL_FUNCTION 1
12 POP_TOP
14 JUMP_ABSOLUTE 6
16 POP_BLOCK
4 >> 18 LOAD_CONST 1 (4)
20 STORE_NAME 2 (b)
22 LOAD_CONST 2 (None)
24 RETURN_VALUE
$ python3.8 -m dis < whiletrue.py 1 0 LOAD_CONST 0 (1) 2 STORE_NAME 0 (a)3 >> 4 LOAD_NAME 1 (print)
6 LOAD_NAME 0 (a)
8 CALL_FUNCTION 1
10 POP_TOP
12 JUMP_ABSOLUTE 4
4 14 LOAD_CONST 1 (4)
16 STORE_NAME 2 (b)
18 LOAD_CONST 2 (None)
20 RETURN_VALUE
I understand why we want to make these optimizations. It's good for those times when we run our programs. But there are other times: when we are analyzing programs.
I'm begging you: please please please help me get https://bugs.python.org/issue2506 implemented (a way to disable optimizations). It is becoming more and more difficult to write tools that analyze Python programs.
People are testing their libraries on Python 3.8-dev, and reporting problems using coverage.py. I would like to support their efforts to test on the daily Python builds. But it's difficult to keep coverage.py working under these conditions.
Anything you can do would be really appreciated.
1st1 commentedon Oct 4, 2018
While I agree with you that we need a flag to disable optimizations, this particular change isn't related to AST or peephole optimizers.
See the bpo-17611 for more details (or 520b7ae)
nedbat commentedon Oct 4, 2018
Yury, thanks. I haven't read the code in depth. I assume there is some place that notices that the while condition is a constant, and therefore doesn't need to be explicitly evaluated? That test can be disabled, yes?
1st1 commentedon Oct 4, 2018
It's more complicated than that: there's no more SETUP_LOOP opcode anymore. The ceval and compiler parts responsible for evaluating and compiling loops were rewritten. FWIW the goal was more about simplifying the needlessly complicated implementation and long term maintenance than about performance. So this is something that coverage will probably have to adapt to (peephole optimizer is another topic).
1st1 commentedon Oct 4, 2018
Ah, I see what you're asking about. I'll need to double check that.
1st1 commentedon Oct 4, 2018
To answer your question: yes, and it's unrelated to both peephole optimizer and to the above mentioned grand refactoring of the ceval loop :) But if we add "-X noopt" (or equivalent) we can disable those micro-optimizations too.
Let's track this in #9693
iritkatriel commentedon Jan 28, 2022
Does PEP-626 help with this problem?
AA-Turner commentedon May 28, 2022
The related #46758 was closed, this issue may no longer be relevant?
A