Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

gh-131798: JIT: Further optimize_CALL_ISINSTANCE for class tuples#134543

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
tomasr8 wants to merge7 commits intopython:main
base:main
Choose a base branch
Loading
fromtomasr8:jit-tuple-isinstance

Conversation

tomasr8
Copy link
Member

@tomasr8tomasr8 commentedMay 22, 2025
edited by bedevere-appbot
Loading

We can already const evalisinstance(inst, cls) calls when both arguments are known, but only ifcls is a single class (e.g.int).
This PR adds support forisinstance(inst, (cls1, cls2, ..., clsN)). This allows us to optimize for example:

  • isinstance(42, (int, str)) (toTrue)
  • isinstance(42, (bool, str)) (toFalse)

We can narrow toTrue even when only some of the classes are known, as long asinst is an instance of one of the known classes.

@tomasr8tomasr8 changed the titlegh-134369: JIT: Further optimize_CALL_ISINSTANCE for class tuplesgh-131798: JIT: Further optimize_CALL_ISINSTANCE for class tuplesMay 22, 2025
Comment on lines +2124 to +2125
self.assertIn("_BUILD_TUPLE", uops)
self.assertIn("_POP_CALL_TWO_LOAD_CONST_INLINE_BORROW", uops)
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

_BUILD_TUPLE is preventing us from optimizing out_POP_CALL_TWO_LOAD_CONST_INLINE_BORROW.
The bytecode is basically:

LOAD_CONSTLOAD_CONST_BUILD_TUPLE_POP_CALL_TWO_LOAD_CONST_INLINE_BORROW

To optimize this, we'd need some special handling for_BUILD_TUPLE inremove_unneeded_uops.

@@ -938,6 +938,9 @@ dummy_func(void) {
}

op(_CALL_ISINSTANCE, (unused, unused, instance, cls -- res)) {
// The below define is equivalent to PyObject_TypeCheck(inst, cls)
#define sym_IS_SUBTYPE(inst, cls) ((inst) == (cls) || PyType_IsSubtype(inst, cls))
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

I'm not sure about this define, maybe it's fine to duplicate this logic?

Copy link
Member

Choose a reason for hiding this comment

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

I'll let you choose. We should probably either duplicate it, or just make it a proper function inoptimizer_symbols.c.

tomasr8 reacted with thumbs up emoji
@tomasr8tomasr8 marked this pull request as ready for reviewMay 22, 2025 22:34
Comment on lines 974 to 979
if (!sym_has_type(item)) {
// There is an unknown item in the tuple,
// we can no longer deduce False.
all_items_known = false;
continue;
}
Copy link
Member

Choose a reason for hiding this comment

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

We can't inferanything in this case, since the class could doanything in its__instancecheck__ or whatever, so it's no longer side-effect free. Need to bail on the whole optimization at this point.

So I don't think we needall_items_known, either. We can either:

  • Break early on our firstTrue, like you do below, and inferTrue.
  • Loop overeverything and inferFalse.
  • Bail on an unknown thing and inferbool.

Copy link
Member

Choose a reason for hiding this comment

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

I guess we could still do something like this if we knowsym_get_type(item) == &PyType_Type, so it's guaranteed side-effect-free, we just don't know the result of the test. But that seems like a rare case (knowing something is atype, but not which type it actually is).

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

We can't infer anything in this case, since the class could do anything in itsinstancecheck or whatever, so it's no longer side-effect free. Need to bail on the whole optimization at this point.

Just to check if I understood this point: even if we have something likeisinstance(42, (unknown, int)) we can't inferTrue because ifunknown defines its own__instancecheck__, it would change the semantics of the program if we inferTrue. This is becauseunknown.__instancecheck__ would no longer be called, right?

So basically what you said, once we see an item with an unknown type, we must stop.

Copy link
Member

@brandtbucherbrandtbucherJul 3, 2025
edited
Loading

Choose a reason for hiding this comment

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

Basically, yeah. It's a bit more subtle, though: wecan infer the result to beTrue, but wecan't remove theisinstance call itself.

So we can set areplace_op = false flag or something to keep the inferred value but avoid theREPLACE_OP call. That would at least allow us to remove the following branch inif isinstance(42, (has_metaclass, int)): ..., even if theisinstance call itself remains.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Basically, yeah. It's a bit more subtle, though: we can infer the result to be True, but we can't remove the isinstance call itself.

Awesome, that was pretty much my understanding as well :)

I'll fix the PR hopefully this weekend.

@@ -938,6 +938,9 @@ dummy_func(void) {
}

op(_CALL_ISINSTANCE, (unused, unused, instance, cls -- res)) {
// The below define is equivalent to PyObject_TypeCheck(inst, cls)
#define sym_IS_SUBTYPE(inst, cls) ((inst) == (cls) || PyType_IsSubtype(inst, cls))
Copy link
Member

Choose a reason for hiding this comment

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

I'll let you choose. We should probably either duplicate it, or just make it a proper function inoptimizer_symbols.c.

tomasr8 reacted with thumbs up emoji
@bedevere-app
Copy link

When you're done making the requested changes, leave the comment:I have made the requested changes; please review again.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@brandtbucherbrandtbucherbrandtbucher requested changes

@Fidget-SpinnerFidget-SpinnerAwaiting requested review from Fidget-SpinnerFidget-Spinner is a code owner

Assignees
No one assigned
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@tomasr8@brandtbucher

[8]ページ先頭

©2009-2025 Movatter.jp