gh-133672: Allow LOAD_FAST to be optimized to LOAD_FAST_BORROW #133721
Conversation
reference is unconsumed at the end of a basic block, as long as it's otherwise safe to borrow (not killed and not stored as a local).
|
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 |
There was a problem hiding this comment.
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
|
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 |
|
@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:
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. |
The
LOAD_FAST_BORROWinstruction (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_UNCONSUMEDflag), we wouldn't perform the optimization.However, (if I understood this correctly) there are cases where it's perfectly safe to use
LOAD_FAST_BORROWeven when the value is still on the stack at the end of a basic block. The optimization is safe as long as:SUPPORT_KILLEDflag)STORED_AS_LOCALflag)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.
LOAD_FAST_BORROWnot being used even when safe to do so, if value is live at BB end. #133672