Clean up the CALL
sequence
#105848
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.
The bytecode sequence for calls has gotten better in 3.12, but I think it can still be improved in a couple of ways:
NULL
or a tuple ofkwnames
onto the stack immediately before calls, rather than sometimes stashingkwnames
away in a local eval loop variable via theKW_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).CALL
oparg to indicate whether or not to expectkwnames
on the stack. This should get rid of lots of newPUSH_NULL
/CALL
pairs.[callable, self, args...]
or[NULL, callable, args...]
on the stack, since it means thatCALL
(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:Linked PRs
KW_NAMES
#105849CALL
's stack #107788KW_NAMES
(again) #108496KW_NAMES
+CALL
withLOAD_CONST
+CALL_KW
#109300The text was updated successfully, but these errors were encountered: