Skip to content

Move const folding to the peephole optimizer #126835

Description

@Eclips4

Feature 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 = 0
eclips4@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

Activity

  1. self-assigned this
    on Nov 15, 2024
  2. Eclips4 commented on Dec 21, 2024

    @Eclips4
    MemberAuthor

    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.

    Footnotes

    1. https://github.com/python/cpython/blob/2a66dd33dfc0b845042da9bb54aaa4e890733f54/Python/codegen.c#L1678-L1691 ↩

  3. WolframAlph commented on Feb 1, 2025

    @WolframAlph
    Contributor

    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.

  4. added a commit that references this issue on Feb 1, 2025
  5. tomasr8 commented on Feb 1, 2025

    @tomasr8
    Member

    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?

  6. WolframAlph commented on Feb 1, 2025

    @WolframAlph
    Contributor

    I am looking into binop folding as well (almost done). Do you want to pass it or should I take something else?

  7. WolframAlph commented on Feb 1, 2025

    @WolframAlph
    Contributor

    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:
            pass

    raises

    File "/Users/yyanchii/Desktop/cpython/internal/t.py", line 2
        case 0 + 0j:
             ^^^^^^
    SyntaxError: patterns may only match literals and attribute lookups

    It is raised from:

    cpython/Python/codegen.c

    Lines 6022 to 6025 in 89fe067

    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?

  8. Eclips4 commented on Feb 2, 2025

    @Eclips4
    MemberAuthor

    @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 :)

  9. WolframAlph commented on Feb 2, 2025

    @WolframAlph
    Contributor

    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

  10. Eclips4 commented on Feb 3, 2025

    @Eclips4
    MemberAuthor

    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?

  11. WolframAlph commented on Feb 3, 2025

    @WolframAlph
    Contributor

    @Eclips4 as I am reading https://docs.python.org/3/library/ast.html#ast.parse, it is not clear to me whether feature_version also works for constant folding case.

  12. WolframAlph commented on Feb 3, 2025

    @WolframAlph
    Contributor

    But I guess Best-effort part makes it clear that one cannot rely on the consistent output.

  13. 130 remaining items

  14. Eclips4 commented on May 5, 2025

    @Eclips4
    MemberAuthor

    @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".

  15. added a commit that references this issue on Jul 12, 2025
  16. added 2 commits that reference this issue on Mar 30, 2026
  17. added a commit that references this issue on Mar 31, 2026
  18. added a commit that references this issue on Mar 31, 2026
  19. added a commit that references this issue on Apr 16, 2026
  20. added a commit that references this issue on Apr 25, 2026
  21. added 2 commits that reference this issue on Apr 26, 2026
  22. flameastro commented on Jul 11, 2026

    @flameastro
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

interpreter-core(Objects, Python, Grammar, and Parser dirs)type-featureA feature request or enhancement

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions