Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

gh-133672: Allow LOAD_FAST to be optimized to LOAD_FAST_BORROW#133721

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
ljfp wants to merge10 commits intopython:main
base:main
Choose a base branch
Loading
fromljfp:fix-issue-133672

Conversation

ljfp
Copy link
Contributor

@ljfpljfp commentedMay 8, 2025
edited by bedevere-appbot
Loading

TheLOAD_FAST_BORROW instruction (op code 86) loads a borrowed reference onto the operand stack, which is a performance optimization that avoids unnecessary reference counting operations.

Previously, we were only applying this optimization when the reference was consumed within the same basic block. If the value was still on the stack at the end of a basic block (indicated by theREF_UNCONSUMED flag), we wouldn't perform the optimization.

However, (if I understood this correctly) there are cases where it's perfectly safe to useLOAD_FAST_BORROW even when the value is still on the stack at the end of a basic block. The optimization is safe as long as:

  1. The supporting reference in the frame isn't killed before the borrowed reference is consumed (checked by theSUPPORT_KILLED flag)
  2. The borrowed reference isn't stored as a local (checked by theSTORED_AS_LOCAL flag)

This fix allows us to optimize more cases, which is seems to be particularly important for the virtual iterators implementation (PR#132555) where the iterable for a loop is often live at basic block end.

reference is unconsumed at the end of a basic block, as long as it'sotherwise safe to borrow (not killed and not stored as a local).
@bedevere-app
Copy link

Most changes to Pythonrequire a NEWS entry. Add one using theblurb_it web app or theblurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply theskip news label instead.

Copy link
Contributor

@mpagempage left a comment
edited
Loading

Choose a reason for hiding this comment

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

Thanks for working on this! This isn't safe to do unconditionally and will require an analysis that operates on the entire CFG, rather than per basic block. It's only safe to optimize aLOAD_FAST instruction that leaves a value on the stack at the end of a basic block if the other two conditions hold along all paths between the end of the basic block and when the value is popped from the stack. For example, it's not safe to optimize the firstLOAD_FAST inbb0 below because the local is overwritten before the value is consumes from the stack in bb1:

bb0:  LOAD_FAST 0  LOAD_FAST 1  TO_BOOL.   POP_JUMP_IF_FALSE <bb2>bb1:  LOAD_CONST 0  STORE_FAST 0  RETURN_VALUEbb2:  RETURN_VALUE

@bedevere-app
Copy link

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@ljfp
Copy link
ContributorAuthor

@mpage Thanks for your feedback! I've pushed an update that should address cases like the one you mentioned.

The main change involves doing, as suggested, a cfg analysis (using dfs via is_borrow_safe and check_borrow_safety_globally functions). This analysis now:

  • Tracks the borrowed value across basic block boundaries if it's live at the end of a block.
  • Checks along all execution paths if the original local variable backing the borrow is overwritten before the borrowed value is consumed.
  • Verifies that the borrowed value itself isn't stored into another local variable.
  • Detects and handles cycles in the CFG to ensure termination and safety.

I think this way we are properly handling the scenarios like the one you provided and ensuring the LOAD_FAST_BORROW optimization is applied safely.

Could you please take another look when you have a moment?

To be honest, this dived deeper into flowgraph.c than I initially anticipated, and it's a bit outside my usual comfort zone, so any further guidance would be much appreciated if I've missed something or if there are better ways to approach this.

@ljfpljfp requested a review frommpageMay 14, 2025 15:14
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@markshannonmarkshannonAwaiting requested review from markshannonmarkshannon is a code owner

@iritkatrieliritkatrielAwaiting requested review from iritkatrieliritkatriel is a code owner

@mpagempageAwaiting requested review from mpage

Assignees
No one assigned
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@ljfp@mpage

[8]ページ先頭

©2009-2025 Movatter.jp