-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
gh-104584: Support most jumping instructions #106393
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
d31d003
b886ca6
28b3951
0825696
1df7b84
d6235ee
6cd5719
b33a1a2
f5e18d8
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 |
---|---|---|
|
@@ -2715,6 +2715,10 @@ void Py_LeaveRecursiveCall(void) | |
|
||
///////////////////// Experimental UOp Interpreter ///////////////////// | ||
|
||
#undef JUMP_POP_DISPATCH | ||
#define JUMP_POP_DISPATCH(x, n) \ | ||
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. This seems unnecessary. The superblock generator should be converting each conditional jump into a conditional exit, followed by an unconditional jump.
becomes: False branch more likely
True branch more likely
As for which branch is more likely, we will need to record which way branches go. 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. Okay, just so I understand correctly, the idea is that In the other case (branch likely) the But recording which way branches go is something for a future PR; again the most simplistic thing to do for now is to assume that branching is less likely than not branching (i.e., always generate Honestly, for now I think I'll stick to just making the generator explicitly translate 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. I think it makes more sense to consume the condition before exiting These two instructions, There are a number of approaches, for exits. Here are three:
Option 3 makes the superblock creation more complex, but simplifies the tier2 interpreter. If option 3 is too complex for this PR, option 2 should work as a temporary step. So for option 3, using the example above of False branch more likely
True branch more likely
|
||
do { frame->prev_instr += (x); stack_pointer -= (n); goto exit; } while (0) | ||
|
||
#undef DEOPT_IF | ||
#define DEOPT_IF(COND, INSTNAME) \ | ||
if ((COND)) { \ | ||
|
@@ -2772,6 +2776,13 @@ _PyUopExecute(_PyExecutorObject *executor, _PyInterpreterFrame *frame, PyObject | |
#define ENABLE_SPECIALIZATION 0 | ||
#include "executor_cases.c.h" | ||
|
||
case JUMP_TO_TOP: | ||
{ | ||
pc = 0; | ||
CHECK_EVAL_BREAKER(); | ||
break; | ||
} | ||
|
||
case SAVE_IP: | ||
{ | ||
frame->prev_instr = ip_offset + oparg; | ||
|
@@ -2795,6 +2806,12 @@ _PyUopExecute(_PyExecutorObject *executor, _PyInterpreterFrame *frame, PyObject | |
} | ||
} | ||
|
||
exit: | ||
DPRINTF(2, "Jumping!\n"); | ||
_PyFrame_SetStackPointer(frame, stack_pointer); | ||
Py_DECREF(self); | ||
return frame; | ||
|
||
unbound_local_error: | ||
format_exc_check_arg(tstate, PyExc_UnboundLocalError, | ||
UNBOUNDLOCAL_ERROR_MSG, | ||
|
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.
Can we leave dispatch to the code generator?
The saved instruction pointer (
frame->prev_instr
) is part of the VM state like any other, so shouldn't need special casing. Unless the necessary information is not otherwise present. All the information necessary is inJUMPBY(oparg)
.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.
Okay, so you're saying that for Tier 2 the code generator should just replace
JUMPBY(<expr>)
with something Tier-2-appropriate. That could actually work. There are three places where we shouldn't do that,SEND
,JUMP_BACKWARD
andENTER_EXECUTOR
, we can exclude those by forbidding something they use.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.
SEND
will probably need to be broken up into two micro ops, one that does the send, and another that does the jump. TheSEND
jump should be a more-or-less normal jump. We also need to track where we are sending from, to handle the matchingYIELD_VALUE
, so I'd "forbid"SEND
for now.I think you already handle
JUMP_BACKWARD
andENTER_EXECUTOR
correctly. They complete the loop, or exit.