8000 gh-98831: Use opcode metadata for stack_effect() by gvanrossum · Pull Request #101704 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

gh-98831: Use opcode metadata for stack_effect() #101704

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 8 commits into from
Feb 9, 2023
Merged

gh-98831: Use opcode metadata for stack_effect() #101704

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
f59751d
Write output and metadata in a single run
gvanrossum Feb 8, 2023
383c1fc
Declare or define opcode metadata based on NEED_OPCODE_TABLES
gvanrossum Feb 8, 2023
c5db6bc
Use generated metadata for stack_effect()
gvanrossum Feb 8, 2023
683d8f7
compile.o depends on opcode_metadata.h
gvanrossum Feb 8, 2023
a271ebc
Return -1 for unknown opcode
gvanrossum Feb 8, 2023
977e639
Support jump<0 in stack_effect()
gvanrossum Feb 8, 2023
bd19d79
stack_effect() for specialized opcode is an error
gvanrossum Feb 8, 2023
658ea17
Use MAX_REAL_OPCODE as upper opcode limit
gvanrossum Feb 8, 2023
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
Use MAX_REAL_OPCODE as upper opcode limit
  • Loading branch information
@gvanrossum
gvanrossum committed Feb 8, 2023
commit 658ea177d8213773e23926c3440d31e4daea70bf
2 changes: 1 addition & 1 deletion Python/compile.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1074,7 +1074,7 @@ basicblock_next_instr(basicblock *b)
static int
stack_effect(int opcode, int oparg, int jump)
{
if (0 <= opcode && opcode < 256) {
if (0 <= opcode && opcode <= MAX_REAL_OPCODE) {
if (_PyOpcode_Deopt[opcode] != opcode) {
// Specialized instructions are not supported.
return PY_INVALID_STACK_EFFECT;
Copy link
Member

Choose a reason for hiding this comment

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

Wouldn't it be correct to return the stack effect of _PyOpcode_Deopt[opcode]?

Copy link
Member Author

Choose a reason for hiding this comment

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

Wouldn't it be correct to return the stack effect of _PyOpcode_Deopt[opcode]?

I thought so, but there are unit tests that insist that this is an error, and I didn't feel like changing the tests:

        # All not defined opcodes
        for code in set(range(256)) - set(dis.opmap.values()):
            with self.subTest(opcode=code):
                self.assertRaises(ValueError, stack_effect, code)
                self.assertRaises(ValueError, stack_effect, code, 0)

Copy link
Member

Choose a reason for hiding this comment

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

Ah, those tests probably predate specialization. We don't need to change this now.

Copy link
Member Author

Choose a reason for hiding this comment

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

opcode.py goes to great lengths to hide the existence of specialized instructions -- they don't show in either opname or opmap, even though pseudo ops do exist there. So I think it's by design. Though we could argue for changing that design.

I found the algorithm in dis.py on L46-52. I think it's duplicated in Tools/build/generate_opcode_h.py on L145-151.

Copy link
Member

Choose a reason for hiding this comment

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

I think dis.py:46-52 is actually allocating unused opcodes for the specialised instructions, while generate_opcode_h.py:145-151 is building the full deopt lookup table from opcode["_specializations"], plus mapping each normal opcode to itself.

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh wait, in generate_opcode_h.py it's L101-107. These two algorithms ought to match, otherwise results will be hilarious. :-)

Anyway, I'm going to merge now. On to figuring out whether mark_stacks() is in reach yet (I doubt it).

Copy link
Member

Choose a reason for hiding this comment

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

Ah yes. Wow, we need to fix that.

Expand Down
0