GH-105848: Simplify the arrangement of CALL's stack#107788
Merged
brandtbucher merged 6 commits intopython:mainfrom Aug 9, 2023
Merged
GH-105848: Simplify the arrangement of CALL's stack#107788brandtbucher merged 6 commits intopython:mainfrom
CALL's stack#107788brandtbucher merged 6 commits intopython:mainfrom
Conversation
Loading
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Instead of supporting both
[callable, self, args...]and[NULL, callable, args...], changeCALL's stack to be[callable, self_or_null, args...]. This always puts the desired callable at the same location on the stack, simplifying (or removing) the resulting shuffles and adjustments necessary for the shared code paths that follow.This also changes
CALL_FUNCTION_EX,DICT_MERGE,LOAD_ATTR,LOAD_GLOBAL,LOAD_SUPER_ATTRto support the new stack layout. In some cases, I've also changed the names of the stack items for consistency within a family.As a side-effect of the new layout,
LOAD_ATTR_PROPERTYandLOAD_ATTR_GETATTRIBUTE_OVERRIDDEN(which are both implemented as inlined calls) don't support pushing an additional item to the stack for a followingCALL(oparg & 1) anymore. I think this is fine, since it seems rare to call a "method" that's looked up in this manner.CALLsequence #105848