-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
gh-92228: disable the compiler's 'small exit block inlining' optimization for blocks that have a line number #94592
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
Conversation
Does the PR need yet another bytecode magic bump or can we piggy-back on the magic bump that was merged yesterday? |
I think it's safe to piggyback. In any case, we didn't change the set of opcodes so I think the old code would normally still work (unless you ask the compiler to jump over an except block to a small exit block). |
Misc/NEWS.d/next/Core and Builtins/2022-07-06-14-02-26.gh-issue-92228.44Cbly.rst
Outdated
Show resolved
Hide resolved
Benchmark results show no difference overall:
|
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.
Tests are passing, benchmark shows no impact, C code changes look fine, test changes are plausible. I trust you know what you are doing, too. 👍
Thanks @iritkatriel for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11. |
Sorry, @iritkatriel, I could not cleanly backport this to |
…ing' optimization for blocks that have a line number (pythonGH-94592) Inlining of code that corresponds to source code lines, can make it hard to distinguish later between code which is only reachable from except handlers, and that which is reachable in normal control flow. This caused problems with the debugger's jump feature. This PR turns off the inlining optimisation for code which has line numbers. We still inline things like the implicit "return None".. (cherry picked from commit bde06e1) Co-authored-by: Irit Katriel <[email protected]>
GH-94643 is a backport of this pull request to the 3.11 branch. |
…timization for blocks that have a line number (pythonGH-94592) Inlining of code that corresponds to source code lines, can make it hard to distinguish later between code which is only reachable from except handlers, and that which is reachable in normal control flow. This caused problems with the debugger's jump feature. This PR turns off the inlining optimisation for code which has line numbers. We still inline things like the implicit "return None".
…ptimization for blocks that have a line number (GH-94592) (GH-94643) Inlining of code that corresponds to source code lines, can make it hard to distinguish later between code which is only reachable from except handlers, and that which is reachable in normal control flow. This caused problems with the debugger's jump feature. This PR turns off the inlining optimisation for code which has line numbers. We still inline things like the implicit "return None".. (cherry picked from commit bde06e1) Co-authored-by: Irit Katriel <[email protected]>
Quick question: what other "things" could possibly not have a line number besides the implicit |
Inlining of code that corresponds to source code lines, can make it hard to distinguish later between code which is only reachable from except handlers, and that which is reachable in normal control flow. This caused problems with the debugger's jump feature.
This PR turns off the inlining optimisation for code which has line numbers. We still inline things like the implicit "return None".
Automerge-Triggered-By: GH:tiran