8000 GH-118093: Handle some polymorphism before requiring progress in tier two by brandtbucher · Pull Request #122843 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

GH-118093: Handle some polymorphism before requiring progress in tier two #122843

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.

Sign up for GitHub

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

Merged
merged 11 commits into from
Aug 12, 2024
Merged

GH-118093: Handle some polymorphism before requiring progress in tier two #122843

Changes from 1 commit
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
1e6df25
Don't require progress on side exits
brandtbucher Jul 13, 2024
c88b70d
Add an upper bound on side exit chaining before progress is required …
brandtbucher Jul 13, 2024
5165880
Clean things up
brandtbucher Jul 18, 2024
63b5207
We still need to translate an instruction, even if progress isn't needed
brandtbucher Jul 30, 2024
17a27d0
Stitch to ENTER_EXECUTOR during projection
brandtbucher Aug 8, 2024
133aa69
Clean up the diff
brandtbucher Aug 8, 2024
a5bdc9f
blurb add
brandtbucher Aug 8, 2024
94c9308
fixup
brandtbucher Aug 8, 2024
037b3fe
Clean up the diff
brandtbucher Aug 8, 2024
45c34a3
Pack some small _PyVMData members into a bitfield
brandtbucher Aug 12, 2024
167df29
Add clarifying comments and fix style
brandtbucher Aug 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Add clarifying comments and fix style
  • Loading branch information
@brandtbucher
brandtbucher committed Aug 12, 2024
commit 167df2996d91359795cf7ed1b6eb96d9f1567e3f
23 changes: 18 additions & 5 deletions Python/optimizer.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -111,7 +111,8 @@ never_optimize(
_PyInterpreterFrame *frame,
_Py_CODEUNIT *instr,
_PyExecutorObject **exec,
int Py_UNUSED(stack_entries), bool Py_UNUSED(progress_needed))
int Py_UNUSED(stack_entries),
bool Py_UNUSED(progress_needed))
{
// This may be called if the optimizer is reset
return 0;
Expand Down Expand Up @@ -178,8 +179,8 @@ _PyOptimizer_Optimize(
_PyInterpreterFrame *frame, _Py_CODEUNIT *start,
_PyStackRef *stack_pointer, _PyExecutorObject **executor_ptr, int chain_depth)
{
// The first instruction in a chain and the MAX_CHAIN_DEPTH'th instruction
// *must* make progress in order to avoid infinite loops or excessively-long
// The first executor in a chain and the MAX_CHAIN_DEPTH'th executor *must*
// make progress in order to avoid infinite loops or excessively-long
// side-exit chains. We can only insert the executor into the bytecode if
// this is true, since a deopt won't infinitely re-enter the executor:
chain_depth %= MAX_CHAIN_DEPTH;
Expand Down Expand Up @@ -607,6 +608,16 @@ translate_bytecode_to_trace(
}
}
if (opcode == ENTER_EXECUTOR) {
Copy link
Member

Choose a reason for hiding this comment

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

Why are we are done?
If we are wanting specialized traces, they may overlap.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've added a comment justifying the decision.

// We have a couple of options here. We *could* peek "underneath"
// this executor and continue tracing, which could give us a longer,
// more optimizeable trace (at the expense of lots of duplicated
// tier two code). Instead, we choose to just end here and stitch to
// the other trace, which allows a side-exit traces to rejoin the
// "main" trace periodically (and also helps protect us against
// pathological behavior where the amount of tier two code explodes
// for a medium-length, branchy code path). This seems to work
// better in practice, but in the future we could be smarter about
// what we do here:
goto done;
}
assert(opcode != ENTER_EXECUTOR && opcode != EXTENDED_ARG);
Expand Down Expand Up @@ -1233,7 +1244,8 @@ uop_optimize(
_PyInterpreterFrame *frame,
_Py_CODEUNIT *instr,
_PyExecutorObject **exec_ptr,
int curr_stackentries, bool progress_needed)
int curr_stackentries,
bool progress_needed)
{
_PyBloomFilter dependencies;
_Py_BloomFilter_Init(&dependencies);
Expand Down Expand Up @@ -1336,7 +1348,8 @@ counter_optimize(
_PyInterpreterFrame *frame,
_Py_CODEUNIT *instr,
_PyExecutorObject **exec_ptr,
int Py_UNUSED(curr_stackentries), bool Py_UNUSED(progress_needed)
int Py_UNUSED(curr_stackentries),
bool Py_UNUSED(progress_needed)
)
{
PyCodeObject *code = _PyFrame_GetCode(frame);
Expand Down
Loading
0