GeezerVison is showing github.com — Move const folding to the peephole optimizer · Issue #126835 · python/cpython
Move const folding to the peephole optimizer #126835DescriptionFeature or enhancement
Proposal:
For additional context see #126830 (comment).
Flow graph optimizer has more information and can do better job.
The problem is that we need to convert from UNARY_OP(-, CONST(1)) to CONST(-1), still before the code generation phase, because this leads to a few problems, one of which is shown below.
x = 1
match x:
case -0:
y = 0eclips4@nixos ~/p/p/cpython (remove-ast-optimizer)> ./python example.py
File "/home/eclips4/programming/programming-languages/cpython/example.py", line 4
case -0:
^^
SyntaxError: patterns may only match literals and attribute lookups
cc @markshannon
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Linked PRs
Reacted by Tomas R., Xuanteng Huang, W1thLuv, Mikhail Efimov, Michael Kashirin, Yan Yanchii and Tony ActivityEclips4 commented on Dec 21, 2024 We had a discussion with @tomasr8 and decided that splitting this into parts would be good. Initially, I tried to do it in one PR, but realized that it would be impossible to review, as it would do a lot of unrelated things.
To begin, we decided to start by moving tuple folding from AST optimizer to CFG.
Problem: Currently compiler emits a warning if is/is not operators are used with constants1 (because it can evaluate them to True which is an implementation detail of CPython, other implementations might evaluate const is const to False).
So, the compiler (especially the codegen part) assumes that tuples are already folded, and has (in AST terms) Constant_kind. This breaks when we fold tuples later and they have a Tuple_kind at the codegen phase.
Possible solution: Perform this in a CFG after folding. This will be slower (I have no information on how slower it will be, but I assume it will) than performing this in codegen phase.
Reacted by Tomas R., Mikhail Efimov and Michael Kashirin WolframAlph commented on Feb 1, 2025 Is there a plan what parts/in what order should be moved from ast optimizer to cfg? Does it make sense to create sub issues to make it more granular (instead of just PRs linked to this issue)? This issue Remove the AST optimizer seems too general and broad IMO. added a commit that references this issue on Feb 1, 2025gh-126835: Move optimization of constant sequence creation from codeg… tomasr8 commented on Feb 1, 2025 I'm currently looking into moving unaryop/binop folding (though I'm at Fosdem atm so It might take a bit longer) Anything else is up for grabs I'd say, unless Kirill is working on something currently? WolframAlph commented on Feb 1, 2025 I am looking into binop folding as well (almost done). Do you want to pass it or should I take something else? WolframAlph commented on Feb 1, 2025 Problem with binop I discovered is that after moving it to cfg, we, for instance, run into problem with case matching which @Eclips4 mentioned in issue description. For example:
match x:
case 0 + 0j:
passraises
File "/Users/yyanchii/Desktop/cpython/internal/t.py", line 2
case 0 + 0j:
^^^^^^
SyntaxError: patterns may only match literals and attribute lookupsIt is raised from:
|
if (!MATCH_VALUE_EXPR(value)) { |
|
const char *e = "patterns may only match literals and attribute lookups"; |
|
return _PyCompile_Error(c, LOC(p), e); |
|
} |
So at codegen stage, it already expects (in this case) binops to be folded. @tomasr8 did you run into this already? We would need to add more logic in here which doesn't look good to me. On the other hand, how would we move binop folding to CFG then? Eclips4 commented on Feb 2, 2025 @tomasr8 @WolframAlph
I think the current priority is to move unaryop folding from AST optimizer to codegen phase.
I'm looking into it.
Then we should have to think about binaryop folding :) WolframAlph commented on Feb 2, 2025 Placing this here, not to forget in future: #129568 (comment). Maybe in future we get rid of emitting LOAD_SMALL_INT in codegen and let CFG do it instead Eclips4 commented on Feb 3, 2025 cc @iritkatriel
We need to decide on what to do with the optimize parameter of ast.parse and the PyCF_OPTIMIZED_AST flag.
If we remove the AST optimizer, these two will become obsolete.
Should we deprecate them in 3.14 (after the AST optimizer is removed) and remove them in 3.19? WolframAlph commented on Feb 3, 2025 WolframAlph commented on Feb 3, 2025 But I guess Best-effort part makes it clear that one cannot rely on the consistent output.
Eclips4 commented on May 5, 2025
@Eclips4 does this change deserve having "What's New" entry? Seems like not very interesting to the end user. Or am I wrong?
I guess some users may have been relying on the behavior of the previous ast optimizer, but now it's gone.
There was no explanation of exactly what ast.parse(optimize=1) does, but even with that some users may still have used it.
So, I think we should at least "warn" them in "What's new". Reacted by Mikhail Efimov and Irit Katriel added 2 commits that reference this issue on Apr 26, 2026gh-146455: Fix O(N²) in add_const() after constant folding moved to C… flameastro commented on Jul 11, 2026
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|