Skip to content

gh-132732: Automatically constant evaluate pure operations #132733

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 35 commits into
base: main
Choose a base branch
from
Open

gh-132732: Automatically constant evaluate pure operations #132733

wants to merge 35 commits into from
+554 −212

Conversation

Fidget-Spinner
Copy link
Member

@Fidget-Spinner Fidget-Spinner commented Apr 19, 2025 •
edited by bedevere-app bot
Loading

@python-cla-bot
Copy link

python-cla-bot bot commented Apr 19, 2025 •
edited
Loading

All commit authors signed the Contributor License Agreement.

CLA signed

@Fidget-Spinner Fidget-Spinner requested review from brandtbucher and removed request for markshannon April 19, 2025 16:21
@bedevere-app bedevere-app bot mentioned this pull request Apr 19, 2025
Open
@brandtbucher brandtbucher mentioned this pull request Apr 24, 2025
Merged
brandtbucher
brandtbucher reviewed Apr 24, 2025
View reviewed changes
Copy link
Member

@brandtbucher brandtbucher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really neat!

Other than two opcodes I found that shouldn't be marked pure, I just have one thought:

Rather than rewriting the bodies like this to use the symbols-manipulating functions (which seems error-prone), would we be able to just use stackrefs to do this?

For example, _BINARY_OP_ADD_INT is defined like this:

PyObject *left_o = PyStackRef_AsPyObjectBorrow(left);
PyObject *right_o = PyStackRef_AsPyObjectBorrow(right);
// ...
res = PyStackRef_FromPyObjectSteal(res_o);

Rather than rewriting uses of these functions, could it be easier to just do something like this, since we're guranteed not to escape?

if (sym_is_const(ctx, stack_pointer[-2]) && sym_is_const(ctx, stack_pointer[-1])) {
    // Generated code to turn constant symbols into stackrefs:
    _PyStackRef left = PyStackRef_FromPyObjectBorrow(sym_get_const(ctx, stack_pointer[-2]));
    _PyStackRef right = PyStackRef_FromPyObjectBorrow(sym_get_const(ctx, stack_pointer[-1]));
    _PyStackRef res;
    // Now the actual body, same as it appears in executor_cases.c.h:
    PyObject *left_o = PyStackRef_AsPyObjectBorrow(left);
    PyObject *right_o = PyStackRef_AsPyObjectBorrow(right);
    // ...
    res = PyStackRef_FromPyObjectSteal(res_o);
    // Generated code to turn stackrefs into constant symbols:
    stack_pointer[-1] = sym_new_const(ctx, PyStackRef_AsPyObjectSteal(res));
}

I'm not too familiar with the design of the cases generator though, so maybe this is way harder or something. Either way, I'm excited to see this get in!

@Fidget-Spinner
Copy link
Member Author

Rather than rewriting uses of these functions, could it be easier to just do something like this, since we're guranteed not to escape?

Seems feasible. I could try to rewrite all occurences of the variable with a stackref-producing const one. Let me try that.

@Fidget-Spinner
Copy link
Member Author

I've verified no refleak on test_capi.test_opt locally apart from #132731 which is pre-existing.

@Fidget-Spinner Fidget-Spinner mentioned this pull request Apr 26, 2025
Merged
@markshannon
Copy link
Member

There's a lot going on in this PR, probably too much for one PR.

Could we start with a PR to fix up the pure annotations so that they are on the correct instructions and maybe add the pure_guard annotation that Brandt suggested?

@markshannon
Copy link
Member

Could we have the default code generator generate a function for the body of the pure instruction and then call that from the three interpreters?

@brandtbucher
Copy link
Member

Could we have the default code generator generate a function for the body of the pure instruction and then call that from the three interpreters?

Hm, I think I’d prefer not to. Sounds like it could hurt performance, especially for the JIT (where things can’t inline).

@brandtbucher
Copy link
Member

I think a good progression would be:

  • Implement the pure attribute, and the optimizer changes. Remove the pure attributes where they don’t belong (so nothing breaks) and leave the existing ones as proof that the implementation works. (This PR)
  • Audit the existing non-pure bytecodes and add pure where it makes sense. (Follow-up PR)
  • Implement the pure_guard attribute, and annotate any bytecodes that can use it. (Follow-up PR)

@Fidget-Spinner
Copy link
Member Author

Could we have the default code generator generate a function for the body of the pure instruction and then call that from the three interpreters?

Hm, I think I’d prefer not to. Sounds like it could hurt performance, especially for the JIT (where things can’t inline).

I thought about this and I think we can inline if we autogenerate a header file and include that directly. But then we're at the mercy of the compiler in both the normal interpreter and the JIT deciding to inline or not to inline the body again. Which I truly do not want.

@Fidget-Spinner
Copy link
Member Author

@brandtbucher @markshannon what can I do to get this PR moving?

@tomasr8 if youd like to review, here's a summary of the PR:

  1. If a bytecode operation is pure (no side effects) we can mark it as pure in bytecodes.c.
  2. In the optimizer, we automatically generate the body that does evaluation of the symbolic constants by copy pasting the bytecodes.c definition into the optimizer's C code. Of course we check that the inputs are constants first.
  3. All changes to the cases generator is for the second point.

@tomasr8
Copy link
Member

tomasr8 commented May 8, 2025

Thanks for the ping! I actually wanted to try/review this PR, I was just very busy this week with work :/ I'll have a look this weekend :)

tomasr8
tomasr8 reviewed May 9, 2025
View reviewed changes
Copy link
Member

@tomasr8 tomasr8 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only had time to skim the PR, I'll do a more thorough review this weekend :)

@Fidget-Spinner @tomasr8
Apply changes from code review
8ae38c7 
Co-Authored-By: Tomas R. <tomas.roun8@gmail.com>
@brandtbucher
Copy link
Member

This is also making me realize that we really should make it possible to detect refleaks/memory leaks on JIT builds soon. The problem is that new executors are allocated all over the place, leading to things like #120501.

@Fidget-Spinner
Copy link
Member Author

I will merge this by tomorrow, if there are no more objections.

markshannon
markshannon requested changes May 28, 2025
View reviewed changes
Copy link
Member

@markshannon markshannon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, I think we should be explicit in optimizer_bytecodes.c about where the optimization is being applied for a couple of reasons:

  • Purity is more a function of the operands than the instruction. BINARY_OP is pure if passed two ints. BINARY_OP_ADD is not pure if passed two objects where addition has side effects.
  • Code clarity and cleanliness
    REPLACE_OPCODE_IF_EVALUTES_PURE(left, right);

is tidier and more explicit than

        // We need to tell the cases generator that it's being used by the constant generator.
        // We should fix this in the cases generator.
        (void)(left);
        (void)(right);

plus it can be added to BINARY_OP as well.

@bedevere-app
Copy link

bedevere-app bot commented May 28, 2025

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

@Fidget-Spinner
Copy link
Member Author

I have made the requested changes; please review again

@bedevere-app
Copy link

bedevere-app bot commented May 28, 2025

Thanks for making the requested changes!

@markshannon: please review the changes made to this pull request.

@bedevere-app bedevere-app bot requested a review from markshannon May 28, 2025 14:04
@Fidget-Spinner
Copy link
Member Author

@markshannon do you have any other comments? I think this has gone through enough rounds of review by you, Brandt, and Tomas, which I'm thankful for.

Fidget-Spinner
Fidget-Spinner commented Jun 6, 2025
View reviewed changes
@noamcohen97 noamcohen97 mentioned this pull request Jun 7, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@StanFromIreland StanFromIreland StanFromIreland left review comments

@tomasr8 tomasr8 tomasr8 approved these changes

@markshannon markshannon Awaiting requested review from markshannon markshannon is a code owner

@brandtbucher brandtbucher Awaiting requested review from brandtbucher

Assignees
No one assigned
Labels
awaiting change review
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@Fidget-Spinner @markshannon @brandtbucher @tomasr8 @StanFromIreland