-
Notifications
You must be signed in to change notification settings - Fork 19
jit: eliminate the guard-fail resume-decode backxlat inverse (jitcode-blackhole Slice 3') #727
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
53e6e56
13138a7
c72b3c9
9f1bc8b
d495cbb
e623a80
7dae04a
8d08ccd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8036,6 +8036,7 @@ pub fn build_state_field_snapshot( | |
| snapshot_frames.push(crate::recorder::SnapshotFrame { | ||
| jitcode_index, | ||
| pc: frame.pc as u32, | ||
| py_pc: frame.pc as u32, | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🎯 Functional Correctness | 🔴 Critical | 🏗️ Heavy lift Store the forward-mapped Python PC, not
As per coding guidelines, the generated JIT must preserve interpreter semantics; a coordinate mismatch is a generation defect, not an acceptable porting difference. 🤖 Prompt for AI AgentsSource: Coding guidelines |
||
| boxes, | ||
| }); | ||
| } | ||
|
|
||
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.
When a multi-frame guard resumes at a JitCode PC whose forward Python PC differs from
backxlat_py_pc(the trivia/after-residual/branch coordinates this field is meant to preserve), the bridge-reconstruction path still ignoresRebuiltFrame.py_pc:reconstruct_inline_recipederivespy_pcwithbackxlat_py_pc(frame.jitcode_index, frame.pc)inpyre/pyre-jit-trace/src/state.rs:5927, and the bridge carrier still re-inverts root/recipe PCs intrace.rs:588,trace.rs:1048, andtrace.rs:1237. That makes the new decoded field unused for inline bridge setup, so it can compute stack depth or pending-result slots from the wrong Python opcode and either drain otherwise valid bridges or rebuild an inlined callee at the wrong resume point. Please carry thispy_pcthrough the carrier/recipe and use it in those consumers instead of the inverse.Useful? React with 👍 / 👎.