Skip to content
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.

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

Clean up the CALL sequence #105848

Closed
brandtbucher opened this issue Jun 16, 2023 · 1 comment
Closed

Clean up the CALL sequence #105848

brandtbucher opened this issue Jun 16, 2023 · 1 comment
Assignees
Labels
3.13 bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage triaged The issue has been accepted as valid by a triager.

Comments

@brandtbucher
Copy link
Member

brandtbucher commented Jun 16, 2023

The bytecode sequence for calls has gotten better in 3.12, but I think it can still be improved in a couple of ways:

  • First, we can start either pushing NULL or a tuple of kwnames onto the stack immediately before calls, rather than sometimes stashing kwnames away in a local eval loop variable via the KW_NAMES opcode. This should free up a register around calls, and it's nice to do anyways since it makes the bytecode more regular (and the stack is really where this sort of stuff belongs).
  • Once that is done, we can use the low bit of the CALL oparg to indicate whether or not to expect kwnames on the stack. This should get rid of lots of new PUSH_NULL/CALL pairs.
  • Separate from the above, but still sort of related: it's a bit awkward that our method call optimization either leaves [callable, self, args...] or [NULL, callable, args...] on the stack, since it means that CALL (and most of its specializations) have to do an awkward swap in order to load the "correct" callable. This can be simplified by always entering calls with [callable, self_or_null, args...] on the stack, so that the callable is always in the same position.

After this is all said and done, the CALL stack effect will look something like:

inst(CALL, (counter/1, cache/2, callable, self_or_null, args[oparg >> 1], kwnames if (oparg & 1) -- res)) {
    // ...
}

Linked PRs

@hugovk
Copy link
Member

hugovk commented Nov 10, 2023

Anything left to do here, or can we close this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.13 bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage triaged The issue has been accepted as valid by a triager.
Projects
None yet
Development

No branches or pull requests

2 participants