GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — gh-133672: Allow LOAD_FAST to be optimized to LOAD_FAST_BORROW by ljfp · Pull Request #133721 · python/cpython

Conversation

@ljfp

@ljfp ljfp commented May 8, 2025 •
edited by bedevere-app Bot
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

The LOAD_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 the REF_UNCONSUMED flag), we wouldn't perform the optimization.

However, (if I understood this correctly) there are cases where it's perfectly safe to use LOAD_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 the SUPPORT_KILLED flag)
  2. The borrowed reference isn't stored as a local (checked by the STORED_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.

  • Issue: LOAD_FAST_BORROW not being used even when safe to do so, if value is live at BB end. #133672

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@ljfp
ljfp requested review from iritkatriel and markshannon as code owners May 8, 2025 23:51
@bedevere-app bedevere-app Bot mentioned this pull request May 8, 2025
LOAD_FAST_BORROW not being used even when safe to do so, if value is live at BB end. #133672
Open
@bedevere-app

bedevere-app Bot commented May 8, 2025

Copy link
Copy Markdown

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

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

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@bedevere-app bedevere-app Bot added the awaiting review label May 8, 2025
@ZeroIntensity
ZeroIntensity requested a review from mpage May 9, 2025 00:06
mpage
mpage requested changes May 9, 2025
View reviewed changes

@mpage mpage left a comment •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

There was a problem hiding this comment.

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 a LOAD_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 first LOAD_FAST in bb0 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_VALUE

bb2:
  RETURN_VALUE

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@bedevere-app bedevere-app Bot added awaiting changes and removed awaiting review labels May 9, 2025
@bedevere-app

bedevere-app Bot commented May 9, 2025

Copy link
Copy Markdown

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 phrase I 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.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@ljfp

ljfp commented May 14, 2025

Copy link
Copy Markdown
Contributor Author

@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.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@ljfp
ljfp requested a review from mpage May 14, 2025 15:14
@Fidget-Spinner

Fidget-Spinner commented May 26, 2025

Copy link
Copy Markdown
Member

Could you please check out the test failures? I'll try to give this PR a look if Matt doesn't get to it first :).

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@ljfp
ljfp requested review from a team, FFY00, brettcannon, emmatyping, ericsnowcurrently, ezio-melotti, freakboy3742, gpshead, jaraco, lysnikolaou, pablogsal, picnixz, terryjreedy, tomasr8, vsajip and warsaw as code owners October 12, 2025 01:12
encukou and others added 17 commits April 25, 2026 17:51
@encukou @vstinner @ljfp
pythongh-146636: Improve ABI/feature selection, add new header for it (…
8abf101
…pythonGH-148302)

Improve ABI/feature selection, add new header for it.

Add a test that Python headers themselves don't use
Py_GIL_DISABLED in abi3t: abi3 and abi3t ought to be the
same except the _Py_OPAQUE_PYOBJECT differences.
This is done using the GCC-only poison pragma.

Co-authored-by: Victor Stinner <[email protected]>
@kumaraditya303 @ljfp
pythongh-148907: fix performance regression in `PyType_GetModuleByDef…
71bd452
…` on free-threading (python#148908)
@diegorusso @ljfp
pythonGH-126910: Build/link the JIT shim in the Python interpreter (p…
414a501
…ython#148872)
@DavidCEllis @ashm-dev @ljfp
pythongh-148680: Replace internal names with type_reprs of objects in…
2848310
… string representations of ForwardRef (python#148682)

Co-authored-by: Shamil <[email protected]>
@StanFromIreland @ljfp
pythongh-148735: Fix a UAF in Element.findtext() (python#148738)
3c4d92e
@EoinTrial @picnixz
@StanFromIreland @ljfp
pythongh-148663: Document that calendar.IllegalMonthError inherits …
00416ea
…from both `ValueError` and `IndexError` (python#148664)

Co-authored-by: Bénédikt Tran <[email protected]>
Co-authored-by: Stan Ulbrych <[email protected]>
@hugovk @brianschubert @ljfp
pythongh-132631: Fix "I/O operation on closed file" when parsing JSON…
a17f00e
… Lines file (python#132632)

Co-authored-by: Brian Schubert <[email protected]>
@colesbury @ljfp
pythongh-113956: Make intern_common thread-safe in free-threaded build (
662b7de
pythongh-148886)

Avoid racing with the owning thread's refcount operations when
immortalizing an interned string: if we don't own it and its refcount
isn't merged, intern a copy we own instead. Use atomic stores in
_Py_SetImmortalUntracked so concurrent atomic reads are race-free.
@johnslavik @ljfp
pythongh-145239: Accept unary plus literal pattern (python#148566)
c1a69cf
Add '+' alternatives to signed_number and signed_real_number grammar
rules, mirroring how unary minus is already handled for pattern matching.
Unary plus is a no-op on numbers so the value is returned directly without
wrapping in a UnaryOp node.
@cocolato @ljfp
pythongh-146073: Add fitness/exit quality mechanism for JIT trace fro…
2df1782
…ntend (pythonGH-148089)

* Replaces ad-hoc logic for ending traces with a simple inequality: `fitness < exit_quality`
* Fitness starts high and is reduced for branches, backward edges, calls and trace length
* Exit quality reflect how good a spot that instruction is to end a trace. Closing a loop is very, specializable instructions are very low and the others in between.
@gpshead @ljfp
Improve hash() builtin docstring with caveats. (pythonGH-125229)
ec3caa0
Improve  `hash()` builtin docstring with caveats.

Mention its return type and that the value can be expected to change between
processes (hash randomization).

Why? The `hash` builtin gets reached for and used by a lot of people whether it
is the right tool or not. IDEs surface docstrings and people use pydoc and
`help(hash)`.
@belm0 @sobolevn
@asvetlov @gvanrossum @ljfp
pythongh-108951: add TaskGroup.cancel() (python#127214)
5a4a1a7
Fixes python#108951

Co-authored-by: sobolevn <[email protected]>
Co-authored-by: Andrew Svetlov <[email protected]>
Co-authored-by: Guido van Rossum <[email protected]>
@scoder @ljfp
pythongh-142186: Revert the unintended value change in the `PY_MONITO…
3d4f054
…RING_EVENT_*` values from pythongh-146182 (pythongh-148955)

python#146182 left an unintended change in the `PY_MONITORING_*` macro values. This change reverts that part to avoid a user visible impact.
@iritkatriel @ljfp
pythongh-148973: fix segfault on mismatch between consts size and opa…
cb2c0c7
…rg in compiler (python#148974)
@johnslavik @ljfp
pythongh-148588: Document __lazy_modules__ (python#148590)
aa396a2
@johnslavik @ljfp
pythongh-140287: Handle PYTHONSTARTUP script exceptions in the asyn…
955bef7
…cio REPL (python#140288)
@JelleZijlstra @johnslavik @ljfp
pythongh-148947: dataclasses: fix error on empty __class__ cell (pyth…
efe54da
…on#148948)

Also add a test demonstrating the need for the existing "is oldcls" check.

Co-authored-by: Bartosz Sławecki <[email protected]>
@ljfp
ljfp requested review from AlexWaygood, JelleZijlstra, berkerpeksag, cjw296, encukou, ethanfurman, giampaolo, hauntsaninja and kumaraditya303 as code owners April 25, 2026 15:52
@python-cla-bot

python-cla-bot Bot commented Apr 25, 2026

Copy link
Copy Markdown

The following commit authors need to sign the Contributor License Agreement:

  • [email protected]

CLA not signed

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@ljfp
Merge branch 'main' into fix-issue-133672
cb49c5f
@ljfp

ljfp commented Apr 25, 2026

Copy link
Copy Markdown
Contributor Author

Why was this PR closed? I was just synching my branch with the latest changes from main, after receiving an email saying my PR was marked "stale".

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@ZeroIntensity

ZeroIntensity commented Apr 25, 2026

Copy link
Copy Markdown
Member

Your rebase messed something up, which ended up tagging every codeowner, so everyone is going to get pings in their inbox for all activity on this PR. Please open a new PR.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@mpage mpage mpage requested changes

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

awaiting changes stale Stale PR or inactive for long period of time.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

20 participants

@ljfp @Fidget-Spinner @ZeroIntensity @mpage @StanFromIreland @pablogsal @gpshead @loic-simon @mhsmith @serhiy-storchaka @hugovk @Wulian233 @eendebakpt @jrfk @fionn @MazinSharaf @tim-one @donbarbos @brandtbucher @encukou
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.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.