Skip to content

gh-134889: Fix handling of a few opcodes when optimizing LOAD_FAST #134958

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

Merged
merged 8 commits into from
Jun 4, 2025

Conversation

mpage
Copy link
Contributor

@mpage mpage commented May 31, 2025

We were incorrectly handling a few opcodes that leave their operands on the stack. Treat all of these conservatively; assume that they always leave operands on the stack.

  • FORMAT_SIMPLE leaves its operand on the stack if its a unicode object.
  • GET_YIELD_FROM_ITER leaves its operand on the stack if its a coroutine or generator object.
  • END_SEND leaves the TOS in place.
  • SET_FUNCTION_ATTRIBUTE leaves the TOS in place.
  • PUSH_EXC_INFO leaves the TOS in place.
  • LOAD_SPECIAL may leave the TOS (self) in place.

mpage added 7 commits May 30, 2025 10:09
`FORMAT_SIMPLE` leaves its operand on the stack if its a unicode object.
Since we cannot determine that at analysis (compile) time, treat it
conservatively and assume it always leaves the operand on the stack.
It leaves the function on the stack
`GET_YIELD_FROM_ITER` doesn't consume its operand if its a coroutine
or generator, so treat it conservatively.

`END_SEND` leaves the TOS.
It leaves the TOS in place.
Load special may leave `self` on TOS. Treat it conservatively and
assume it always does.
@mgorny
Copy link
Contributor

mgorny commented May 31, 2025

I suppose this means Python 3.14 is going to see an ABI breakage too, is that correct?

@mpage
Copy link
Contributor Author

mpage commented May 31, 2025

I suppose this means Python 3.14 is going to see an ABI breakage too, is that correct?

I don’t think so. This doesn’t change the binary layout of anything. What about this would cause an ABI breakage?

@thesamesam
Copy link
Contributor

It changed PYC_MAGIC_NUMBER (which is fine if it can't be avoided, it's just a pain if it can be).

@mpage
Copy link
Contributor Author

mpage commented May 31, 2025

It changed PYC_MAGIC_NUMBER (which is fine if it can't be avoided, it's just a pain if it can be).

I think I’m missing something. The magic number changes with every minor release. Since we haven’t released 3.14 yet, bumping the magic number shouldn’t cause any additional pain beyond what’s felt with a normal release.

@mgorny
Copy link
Contributor

mgorny commented May 31, 2025

A few Linux distributions have already engaged in a lot of Python 3.14 testing (at least Fedora and Gentoo I'm aware of), and these systems will be affected by the magic number change.

@hroncok
Copy link
Contributor

hroncok commented May 31, 2025

In Fedora, we can deal with the chnage of the magic number in b3. But the sooner it happens the better.

@mpage mpage marked this pull request as ready for review June 3, 2025 16:07
@mpage mpage requested review from colesbury and Yhg1s June 3, 2025 16:07
@mpage mpage merged commit 6b77af2 into python:main Jun 4, 2025
39 checks passed
@mpage mpage added the needs backport to 3.14 bugs and security fixes label Jun 4, 2025
@miss-islington-app
Copy link

Thanks @mpage for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

@miss-islington-app
Copy link

Sorry, @mpage, I could not cleanly backport this to 3.14 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 6b77af257c25d31f1f137e477cb23e63692ddf29 3.14

mpage added a commit to mpage/cpython that referenced this pull request Jun 5, 2025
…FAST` (python#134958)

We were incorrectly handling a few opcodes that leave their operands on the stack. Treat all of these conservatively; assume that they always leave operands on the stack.

(cherry picked from commit 6b77af2)
@bedevere-app
Copy link

bedevere-app bot commented Jun 5, 2025

GH-135187 is a backport of this pull request to the 3.14 branch.

@bedevere-app bedevere-app bot removed the needs backport to 3.14 bugs and security fixes label Jun 5, 2025
mpage added a commit that referenced this pull request Jun 5, 2025
…_FAST` (#134958) (#135187)

We were incorrectly handling a few opcodes that leave their operands on the stack. Treat all of these conservatively; assume that they always leave operands on the stack.

(cherry picked from commit 6b77af2)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants