gh-126835: Disable tuple folding in the AST optimizer #128802

tomasr8 · 2025-01-13T21:23:19Z

This disables tuple-folding in the AST optimizer which allows the flowgraph to optimize them instead.
Related comment: #126830 (comment)

I've done some local benchmarking with pyperf which showed some speedup for unpack_sequence but it'd be nice to have proper benchmarks for this :)

cc @Eclips4

Issue: Move const folding to the peephole optimizer #126835

Lib/test/test_compile.py

Lib/test/test_opcache.py

markshannon · 2025-01-21T10:37:13Z

Why have tests been removed from test_compile and test_peepholer?
Those test the code after the CFG optimizer has run, so should be unchanged.

The tests in test_opcache should not be removed, but should be changed to keep the unpacking operation by moving the tuple out of the loop.
Instead of:

for ...
    a, b = 1, 2

use

t = 1, 2
for ...
    a, b = t

Eclips4 · 2025-01-21T13:07:10Z

Why have tests been removed from test_compile and test_peepholer? Those test the code after the CFG optimizer has run, so should be unchanged.

test_compile was changed because the test was fundamentally wrong. The name of the test suggests that it tests constant merging, but actually, all the work was done by AST optimizer. Constant merging has never had any relation to this test. In particular, it tested that co_consts for lambda: (257,) would look like a ((257,),) instead of (257, (257,)). Do you think it's worth fixing?

test_peepholer only changed where it tries to fold set into frozenset where one of the elements is constant tuple. Since folding of constant tuples are handled by the CFG, set folding during the AST optimization can't work for such case. We could add folding for sets (not in all cases, only with in operator and where set is a target for for loop) in the follow-up PR.

The tests in test_opcache should not be removed, but should be changed to keep the unpacking operation by moving the tuple out of the loop.

Thank you, for some reason I forgot about non-constant case...

markshannon · 2025-01-21T14:06:59Z

Constant merging has never had any relation to this test. In particular, it tested that co_consts for lambda: (257,) would look like a ((257,),) instead of (257, (257,)). Do you think it's worth fixing?

No. You can remove that test. Try to keep any tests that test behavior, but any that just test artifacts (like the test for lambda: (257,) ) can be removed.

We could add folding for sets (not in all cases, only with in operator and where set is a target for for loop) in the follow-up PR.

Yes, leave that for another PR.

As an aside:
From a quick experiment I did a while ago, I think the only folding that needs to be done before the CFG optimizer is for negative numbers, converting -(1) into -1. I think that can be done in the codegen pass.

Eclips4 · 2025-01-21T14:18:53Z

As an aside: From a quick experiment I did a while ago, I think the only folding that needs to be done before the CFG optimizer is for negative numbers, converting -(1) into -1. I think that can be done in the codegen pass.

I think we could do that in the follow-up PR.
Though, I'm not an parser expert, but when I understood that parser generates ast.UnaryOp node instead of ast.Constant for simple constants like -1, I was confused.
@pablogsal as parser expert, is it hard to do this in the parser?

@markshannon do you think it's ok to merge this PR? This PR only removes parts of test_ast which are basically tests AST optimizations, and incorrect test in test_compile. Any other changes are simply commenting some parts of tests, which we can uncomment later when other optimizations will take place in CFG.

Lib/test/test_peepholer.py

pablogsal · 2025-01-21T14:37:35Z

@pablogsal as parser expert, is it hard to do this in the parser?

This normally should not be done in the parser as the general idea is that the parser gives the most pure AST to the next step in the pipeline and every modification and optimisations happens there. There are many reasons for this but the classical one is to not make the life of formatters and similar tools hard and not to make unparsing harder.

Eclips4 · 2025-01-21T15:41:22Z

There are many reasons for this but the classical one is to not make the life of formatters and similar tools easy

I guess you mean to use the word "hard" here. Otherwise, do the parser team make someone's life harder on purpose? 🤣

pablogsal · 2025-01-21T18:01:38Z

I guess you mean to use the word "hard" here.

Haha, indeed! 😆

Otherwise, do the parser team make someone's life harder on purpose? 🤣

Maybe just our own life 😉

Eclips4 · 2025-01-26T22:05:35Z

FYI, I plan to merge this tomorrow, as this PR is quite small and I don't see any points here which need further discussion. Mark's comments have already been addressed.

iritkatriel

I think this PR will need documentation because ast.parse no longer optimises this, and it's part of the stdlib API. If the optimisations in final bytecode changed then it needs to be mentioned in WhatsNew.

Lib/test/test_ast/test_ast.py

Lib/test/test_peepholer.py

bedevere-app · 2025-01-27T01:14:49Z

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

…en to CFG (#129426) Codegen phase has an optimization that transforms ``` LOAD_CONST x LOAD_CONST y LOAD_CONXT z BUILD_LIST/BUILD_SET (3) ``` -> ``` BUILD_LIST/BUILD_SET (0) LOAD_CONST (x, y, z) LIST_EXTEND/SET_UPDATE 1 ``` This optimization has now been moved to CFG phase to make #128802 work. Co-authored-by: Irit Katriel <[email protected]> Co-authored-by: Yan Yanchii <[email protected]>

… codegen to CFG (python#129426) Codegen phase has an optimization that transforms ``` LOAD_CONST x LOAD_CONST y LOAD_CONXT z BUILD_LIST/BUILD_SET (3) ``` -> ``` BUILD_LIST/BUILD_SET (0) LOAD_CONST (x, y, z) LIST_EXTEND/SET_UPDATE 1 ``` This optimization has now been moved to CFG phase to make python#128802 work. Co-authored-by: Irit Katriel <[email protected]> Co-authored-by: Yan Yanchii <[email protected]>

Eclips4 · 2025-02-22T13:30:20Z

cc @iritkatriel @WolframAlph for review

tomasr8 · 2025-02-22T18:05:10Z

Lib/test/test_peepholer.py

-        # Long tuples should be folded too.
-        code = compile(repr(tuple(range(10000))),'','single')
+        # Long tuples should be folded too, but their length should not
+        # exceed the `STACK_USE_GUIDELINE`


Should we perhaps add a test that tuples longer than STACK_USE_GUIDELINE are in fact not folded?

Not sure about it. At the moment, for constant tuples which are longer than STACK_USE_GUIDELINE will be generated following bytecode:

BUILD_LIST 0 Pairs of LOAD_CONST + LIST_APPEND CALL_INTRINSIC_1 (INTRINSIC_LIST_TO_TUPLE)

Shall we assert that this intrinsic is presented in bytecode?

WolframAlph

Thanks. I did a quick review and left some comments.

WolframAlph · 2025-02-22T17:55:48Z

Lib/test/test_compile.py

-        # Merge constants in tuple or frozenset
-        f1, f2 = lambda: "not a name", lambda: ("not a name",)
-        f3 = lambda x: x in {("not a name",)}
-        self.assertIs(f1.__code__.co_consts[0],
-                      f2.__code__.co_consts[0][0])
-        self.assertIs(next(iter(f3.__code__.co_consts[1])),
-                      f2.__code__.co_consts[0])
-


Why are these tests removed? They are not related. I understand this is failing, but its enough to update co_consts index. Now that tuple is folded later in pipeline, it sits at different index. Right?

This also bring us back to #130016. We wouldn't need to touch this if we were to merge that. @iritkatriel are we planning to?

WolframAlph · 2025-02-22T17:56:07Z

Lib/test/test_peepholer.py

@@ -345,6 +346,28 @@ def negzero():
                self.assertInBytecode(code, opname)
                self.check_lnotab(code)

+    def test_folding_of_tuples_on_constants(self):


Suggested change

def test_folding_of_tuples_on_constants(self):

def test_folding_of_tuples_of_constants(self):

And we actually, already have test_folding_of_tuples_of_constants, maybe we could add more to those instead?

WolframAlph · 2025-02-22T18:02:22Z

Lib/test/test_peepholer.py

+        # Long tuples should be folded too, but their length should not
+        # exceed the `STACK_USE_GUIDELINE`
+        code = compile(repr(tuple(range(30))),'','single')


How much of a concern is that we can no longer create constant tuples beyond length of STACK_USE_GUIDELINE? @iritkatriel

It's probably not ideal in case you have some kind of large constant lookup table for instance. As Kirill pointed out, this would get compiled to a bunch of LOAD_CONST + LIST_APPEND which is probably much slower

It is not a hard pattern to detect, right? Maybe we could fold it anyway? @Eclips4

It seems quite predictable:

>>> def foo(): ... return (1,2,3, ... ,31) ... >>> dis.dis(foo) 1 RESUME 0 2 BUILD_LIST 0 LOAD_SMALL_INT 1 LIST_APPEND 1 LOAD_SMALL_INT 2 LIST_APPEND 1 ... LOAD_SMALL_INT 31 LIST_APPEND 1 CALL_INTRINSIC_1 6 (INTRINSIC_LIST_TO_TUPLE)

(Could also be LOAD_CONST instead of LOAD_SMALL_INT here I suppose)

Exactly. I think we can easily fold it.

Maybe we could check with is_const_tuple if the tuple is constant and if it is, ignore STACK_USE_GUIDELINE because we know it'll be folded by flowgraph anyway.

I don't think it's a good idea. We would be creating dependency between both.

So if we are going to fold constant tuple beyond STACK_USE_GUIDELINE, maybe we could also add this optimization to literal lists & sets? It would be consistent with previous Python version as we are not folding these cases anymore after we migrated them to CFG.

WolframAlph · 2025-02-22T18:08:50Z

Lib/test/test_builtin.py

-        for opt in [opt1, opt2]:
-            opt_right = opt.value.right  # expect Constant((1,2))
-            self.assertIsInstance(opt_right, ast.Constant)
-            self.assertEqual(opt_right.value, (1, 2))
-


This test tests whether we optimize ast when passed PyCF_ONLY_AST/PyCF_OPTIMIZED_AST flag, right? I guess it's not right to just remove lines testing optimized ast. I know there are no more foldings left in ast optimizer, but there is still __debug__ thing left there. So maybe rewrite test to include that?

I think it's ok to modify this one, and remove others from test_ast. I don't think it's worth keeping it. I wrote them to make sure that under different circumstances nodes are still optimized. Since there are no actual foldings (except the __debug__ but it's a special one), I decided to remove them. Changing test_ast tests to use __debug__ seems overhelming to me, IMO

Maybe you're right. They are testing const folding which no longer is there and __debug__ is just special case (which I am not sure we can call const folding either).

WolframAlph · 2025-02-22T18:10:54Z

Lib/test/test_ast/test_ast.py

-    def test_folding_type_param_in_function_def(self):
-        code = "def foo[%s = (1, 2)](): pass"
-
-        unoptimized_tuple = ast.Tuple(elts=[ast.Constant(1), ast.Constant(2)])
-        unoptimized_type_params = [
-            ("T", "T", ast.TypeVar),
-            ("**P", "P", ast.ParamSpec),
-            ("*Ts", "Ts", ast.TypeVarTuple),
-        ]
-
-        for type, name, type_param in unoptimized_type_params:
-            result_code = code % type
-            optimized_target = self.wrap_statement(
-                ast.FunctionDef(
-                    name='foo',
-                    args=ast.arguments(),
-                    body=[ast.Pass()],
-                    type_params=[type_param(name=name, default_value=ast.Constant((1, 2)))]
-                )
-            )
-            non_optimized_target = self.wrap_statement(
-                ast.FunctionDef(
-                    name='foo',
-                    args=ast.arguments(),
-                    body=[ast.Pass()],
-                    type_params=[type_param(name=name, default_value=unoptimized_tuple)]
-                )
-            )
-            self.assert_ast(result_code, non_optimized_target, optimized_target)
-
-    def test_folding_type_param_in_class_def(self):
-        code = "class foo[%s = (1, 2)]: pass"
-
-        unoptimized_tuple = ast.Tuple(elts=[ast.Constant(1), ast.Constant(2)])
-        unoptimized_type_params = [
-            ("T", "T", ast.TypeVar),
-            ("**P", "P", ast.ParamSpec),
-            ("*Ts", "Ts", ast.TypeVarTuple),
-        ]
-
-        for type, name, type_param in unoptimized_type_params:
-            result_code = code % type
-            optimized_target = self.wrap_statement(
-                ast.ClassDef(
-                    name='foo',
-                    body=[ast.Pass()],
-                    type_params=[type_param(name=name, default_value=ast.Constant((1, 2)))]
-                )
-            )
-            non_optimized_target = self.wrap_statement(
-                ast.ClassDef(
-                    name='foo',
-                    body=[ast.Pass()],
-                    type_params=[type_param(name=name, default_value=unoptimized_tuple)]
-                )
-            )
-            self.assert_ast(result_code, non_optimized_target, optimized_target)
-
-    def test_folding_type_param_in_type_alias(self):
-        code = "type foo[%s = (1, 2)] = 1"
-
-        unoptimized_tuple = ast.Tuple(elts=[ast.Constant(1), ast.Constant(2)])
-        unoptimized_type_params = [
-            ("T", "T", ast.TypeVar),
-            ("**P", "P", ast.ParamSpec),
-            ("*Ts", "Ts", ast.TypeVarTuple),
-        ]
-
-        for type, name, type_param in unoptimized_type_params:
-            result_code = code % type
-            optimized_target = self.wrap_statement(
-                ast.TypeAlias(
-                    name=ast.Name(id='foo', ctx=ast.Store()),
-                    type_params=[type_param(name=name, default_value=ast.Constant((1, 2)))],
-                    value=ast.Constant(value=1),
-                )
-            )
-            non_optimized_target = self.wrap_statement(
-                ast.TypeAlias(
-                    name=ast.Name(id='foo', ctx=ast.Store()),
-                    type_params=[type_param(name=name, default_value=unoptimized_tuple)],
-                    value=ast.Constant(value=1),
-                )
-            )
-            self.assert_ast(result_code, non_optimized_target, optimized_target)


Same as with test_compile_ast. Maybe not just remove them, but add testing of __debug__ as it is still in ast optimizer?

WolframAlph · 2025-02-22T18:11:53Z

Lib/test/test_ast/test_ast.py

-    def test_optimization_levels_const_folding(self):
-        folded = ('Expr', (1, 0, 1, 6), ('Constant', (1, 0, 1, 6), (1, 2), None))
-        not_folded = ('Expr', (1, 0, 1, 6),
-                         ('Tuple', (1, 0, 1, 6),
-                             [('Constant', (1, 1, 1, 2), 1, None),
-                             ('Constant', (1, 4, 1, 5), 2, None)], ('Load',)))
-
-        cases = [(-1, not_folded), (0, not_folded), (1, folded), (2, folded)]
-        for (optval, expected) in cases:
-            with self.subTest(optval=optval):
-                tree1 = ast.parse("(1, 2)", optimize=optval)
-                tree2 = ast.parse(ast.parse("(1, 2)"), optimize=optval)
-                for tree in [tree1, tree2]:
-                    res = to_tuple(tree.body[0])
-                    self.assertEqual(res, expected)
-


Same as with test_compile_ast. Maybe add test for __debug__ instead of removing test entirely?

Actually, there is test_optimization_levels__debug__ right above this one, so this one can indeed be gone.

WolframAlph · 2025-03-19T23:13:46Z

@tomasr8 I believe this one can be closed in favour of #130769

tomasr8 added 2 commits January 13, 2025 22:09

Disable tuple folding in the AST optimizer

2f475e1

Provisionally fix tests

7a96d47

bedevere-app bot mentioned this pull request Jan 13, 2025

Move const folding to the peephole optimizer #126835

Open

tomasr8 added the skip news label Jan 13, 2025

Eclips4 self-assigned this Jan 14, 2025

Tweak tests

6d93343

Eclips4 reviewed Jan 16, 2025

View reviewed changes

Lib/test/test_compile.py Outdated Show resolved Hide resolved

Eclips4 reviewed Jan 16, 2025

View reviewed changes

Lib/test/test_opcache.py Outdated Show resolved Hide resolved

Merge branch 'main' into ast-tuple-folding

02a38a3

Restore UNPACK_SEQUENCE_TWO_TUPLE

5c05d69

Eclips4 marked this pull request as ready for review January 21, 2025 14:11

Eclips4 requested review from isidentical, markshannon and iritkatriel as code owners January 21, 2025 14:11

bedevere-app bot added the awaiting review label Jan 21, 2025

Eclips4 reviewed Jan 21, 2025

View reviewed changes

Lib/test/test_peepholer.py Outdated Show resolved Hide resolved

Eclips4 added 2 commits January 21, 2025 16:22

Update Lib/test/test_peepholer.py

05f3e62

Merge branch 'main' into ast-tuple-folding

a3d9790

iritkatriel requested changes Jan 27, 2025

View reviewed changes

Lib/test/test_ast/test_ast.py Outdated Show resolved Hide resolved

Lib/test/test_peepholer.py Outdated Show resolved Hide resolved

bedevere-app bot added awaiting changes and removed awaiting review labels Jan 27, 2025

Eclips4 added 5 commits February 1, 2025 12:05

Merge branch 'main' into ast-tuple-folding

2b39a13

for target optimization (set/list -> frozenset/tuple)

17dffaa

Fold list into a tuple as rhs in for/in operators

46845f0

Fix tests

e9631d8

Merge branch 'main' into ast-tuple-folding

53dfa93

Eclips4 added the skip news label Feb 4, 2025

Eclips4 mentioned this pull request Feb 5, 2025

gh-126835: make CFG optimizer skip over NOP's when looking for const sequence construction #129703

Merged

Eclips4 added 2 commits February 14, 2025 08:18

Merge branch 'main' into ast-tuple-folding

9754820

Fix merge artifacts

477c784

Eclips4 marked this pull request as ready for review February 22, 2025 10:38

bedevere-app bot added the awaiting review label Feb 22, 2025

Eclips4 marked this pull request as draft February 22, 2025 10:38

bedevere-app bot removed the awaiting review label Feb 22, 2025

Eclips4 added 5 commits February 22, 2025 10:39

Merge branch 'main' into ast-tuple-folding

6731dfb

Remove failing tests

aad9fb3

Restore test_peepholer tests

be40093

Add a few tests

5aec965

Restore test

ee69f0f

Eclips4 marked this pull request as ready for review February 22, 2025 13:29

bedevere-app bot added the awaiting review label Feb 22, 2025

Regenerate some files

0801463

Eclips4 requested a review from ericsnowcurrently as a code owner February 22, 2025 14:13

tomasr8 commented Feb 22, 2025

View reviewed changes

WolframAlph reviewed Feb 22, 2025

View reviewed changes

Address review

a268315

Eclips4 closed this Mar 20, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gh-126835: Disable tuple folding in the AST optimizer #128802

gh-126835: Disable tuple folding in the AST optimizer #128802

tomasr8 commented Jan 13, 2025 •

edited by bedevere-app bot

Loading

markshannon commented Jan 21, 2025

Eclips4 commented Jan 21, 2025 •

edited

Loading

markshannon commented Jan 21, 2025

Eclips4 commented Jan 21, 2025

pablogsal commented Jan 21, 2025 •

edited

Loading

Eclips4 commented Jan 21, 2025

pablogsal commented Jan 21, 2025

Eclips4 commented Jan 26, 2025

iritkatriel left a comment

bedevere-app bot commented Jan 27, 2025

Eclips4 commented Feb 22, 2025

tomasr8 Feb 22, 2025

Eclips4 Feb 23, 2025

WolframAlph left a comment

WolframAlph Feb 22, 2025

WolframAlph Feb 22, 2025

WolframAlph Feb 22, 2025

WolframAlph Feb 22, 2025

WolframAlph Feb 22, 2025

tomasr8 Feb 24, 2025

WolframAlph Feb 24, 2025

tomasr8 Feb 24, 2025

WolframAlph Feb 24, 2025

tomasr8 Feb 24, 2025

WolframAlph Feb 24, 2025

WolframAlph Feb 24, 2025 •

edited

Loading

WolframAlph Feb 22, 2025

Eclips4 Feb 23, 2025

WolframAlph Feb 24, 2025

WolframAlph Feb 22, 2025

WolframAlph Feb 22, 2025

WolframAlph Feb 24, 2025

WolframAlph commented Mar 19, 2025

	def test_folding_of_tuples_on_constants(self):
	def test_folding_of_tuples_of_constants(self):

gh-126835: Disable tuple folding in the AST optimizer #128802

gh-126835: Disable tuple folding in the AST optimizer #128802

Conversation

tomasr8 commented Jan 13, 2025 • edited by bedevere-app bot Loading

markshannon commented Jan 21, 2025

Eclips4 commented Jan 21, 2025 • edited Loading

markshannon commented Jan 21, 2025

Eclips4 commented Jan 21, 2025

pablogsal commented Jan 21, 2025 • edited Loading

Eclips4 commented Jan 21, 2025

pablogsal commented Jan 21, 2025

Eclips4 commented Jan 26, 2025

iritkatriel left a comment

Choose a reason for hiding this comment

bedevere-app bot commented Jan 27, 2025

Eclips4 commented Feb 22, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WolframAlph left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WolframAlph Feb 24, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WolframAlph commented Mar 19, 2025

tomasr8 commented Jan 13, 2025 •

edited by bedevere-app bot

Loading

Eclips4 commented Jan 21, 2025 •

edited

Loading

pablogsal commented Jan 21, 2025 •

edited

Loading

WolframAlph Feb 24, 2025 •

edited

Loading