gh-132732: Automatically constant evaluate pure operations #132733
Conversation
Fidget-Spinner
commented
Apr 19, 2025
•
- Issue: Constant evaluate/propagate pure ops automatically #132732
|
All commit authors signed the Contributor License Agreement. |
Misc/NEWS.d/next/Core_and_Builtins/2025-04-19-16-22-47.gh-issue-132732.jgqhlF.rst
Show resolved
Hide resolved
There was a problem hiding this comment.
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!
Seems feasible. I could try to rewrite all occurences of the variable with a stackref-producing const one. Let me try that. |
|
I've verified no refleak on |
|
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 |
|
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 think a good progression would be:
|
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. |