Skip to content

GH-146073: Remove redundancy in _PyJit_TryInitializeTracing#148301

Open
markshannon wants to merge 1 commit intopython:mainfrom
markshannon:simplify-initialize-tracing
Open

GH-146073: Remove redundancy in _PyJit_TryInitializeTracing#148301
markshannon wants to merge 1 commit intopython:mainfrom
markshannon:simplify-initialize-tracing

Conversation

@markshannon
Copy link
Copy Markdown
Member

@markshannon markshannon commented Apr 9, 2026

Copy link
Copy Markdown
Member

@Fidget-Spinner Fidget-Spinner left a comment

Choose a reason for hiding this comment

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

This will likely hurt performance as loops close more rarely.

close_loop_instr points to the loop header. this_instr points to the current jump backwards. When I implemented this, I distinctly remembering wanting to close the loops more frequently. With this change, loops will have to reach the exact same backwards jump to close the loop, which is not want we want as those are unlikely for loops with many backward jumps.

The likelihood of a loop closing via hitting the loop header is significantly higher than hitting the exact same backwards jump found.

@bedevere-app
Copy link
Copy Markdown

bedevere-app bot commented Apr 9, 2026

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

@markshannon
Copy link
Copy Markdown
Member Author

close_loop_instr points to the loop header. this_instr points to the current jump backwards.

The jump backwards immediately precedes the the loop header, so the loop header will never be reached when tracing a loop.

Even if the having two stop points does work better now, they are getting in the way of choosing when to stop tracing with fitness and exit-quality, so we should remove the extra field anyway.

@Fidget-Spinner
Copy link
Copy Markdown
Member

The jump backwards immediately precedes the the loop header, so the loop header will never be reached when tracing a loop.

This is why we check that the jump backwards jumps to close_loop_instr or the start instruction, so another jump backwards will still be able to terminate the trace.

Even if the having two stop points does work better now, they are getting in the way of choosing when to stop tracing with fitness and exit-quality, so we should remove the extra field anyway.

Do you have perf numbers for removing the second stop points? Also if this is the case, I would prefer the stop point be the loop header, not the original JUMP_BACKWARD.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants