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

Appearance settings

gh-131798: JIT: Narrow the return type of isinstance for some known arguments #133172

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 17 commits into from
May 19, 2025

Conversation

tomasr8
Copy link
Member

@tomasr8 tomasr8 commented Apr 29, 2025

In this PR:

  • narrows isintance(obj, cls) to True if obj is a known type and cls is a known class and obj is a subclass of cls (and vice versa for False)
  • in all other cases narrows isinstance to bool.

Brandt also suggested adding an optimization for tuples which I'd like to add in a followup in order to keep the sizes of the individual PRs smaller. Though if you prefer to have it in one PR I can do it as well :)

// isinstance(obj, cls) where both obj and cls have known types
// We can deduce either True or False
PyTypeObject *inst_type = sym_get_type(inst_sym);
if (sym_matches_type(inst_sym, cls) || PyType_IsSubtype(inst_type, cls)) {
Copy link
Member Author

Choose a reason for hiding this comment

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

This simulates PyObject_TypeCheck

Copy link
Member

Choose a reason for hiding this comment

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

Can you add a comment to that effect? :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Added!

@@ -886,6 +886,44 @@ dummy_func(void) {
}
}

op(_CALL_ISINSTANCE, (callable, self_or_null, args[oparg] -- res)) {
if (sym_is_null(self_or_null) || sym_is_not_null(self_or_null)) {
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 seen this guard used elsewhere with self_or_null but it's not clear to me whether it is needed here as well?

Copy link
Member

Choose a reason for hiding this comment

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

Yep. It's just a (weird) way of saying "we know whether it's NULL or not". Maybe it's worth adding a helper function (in another PR) to make it clearer, since the meaning is super subtle.

Copy link
Member

@brandtbucher brandtbucher left a comment

Choose a reason for hiding this comment

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

Cool! Can you also add a test where the second isinstance arg is a class with a metaclass defining __instancecheck__?

class EvenNumberMeta(type):
    def __instancecheck__(self, number):
        return not number % 2

class EvenNumber(metaclass=EvenNumberMeta):
    pass

# Optimizer only narrows to bool, runtime value is True:
even = isinstance(42, EvenNumber)

Comment on lines 1996 to 2008
class Foo:
bar = 42

x = 0
for _ in range(n):
# we only know bar (LOAD_ATTR) is not null (set via sym_new_not_null)
bar = Foo.bar
# This will only narrow to bool and not to True due to 'bar' having
# unknown (non-null) type
y = isinstance(bar, int)
if y:
x += 1
return x
Copy link
Member

Choose a reason for hiding this comment

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

This is pretty fragile: the class attr lookup is cached in the bytecode, and I actually have a branch I'll open a PR with soon that teaches the optimizer to read these caches.

So instead, let's use everyone's favorite optimization-breaker:

Suggested change
class Foo:
bar = 42
x = 0
for _ in range(n):
# we only know bar (LOAD_ATTR) is not null (set via sym_new_not_null)
bar = Foo.bar
# This will only narrow to bool and not to True due to 'bar' having
# unknown (non-null) type
y = isinstance(bar, int)
if y:
x += 1
return x
x = 0
for _ in range(n):
# The optimizer doesn't know the return type here:
bar = eval("42")
# This will only narrow to bool:
y = isinstance(bar, int)
if y:
x += 1
return x

Copy link
Member Author

Choose a reason for hiding this comment

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

Nice trick to use eval! I updated the test :)

Python/bytecodes.c Outdated Show resolved Hide resolved
@@ -886,6 +886,44 @@ dummy_func(void) {
}
}

op(_CALL_ISINSTANCE, (callable, self_or_null, args[oparg] -- res)) {
if (sym_is_null(self_or_null) || sym_is_not_null(self_or_null)) {
Copy link
Member

Choose a reason for hiding this comment

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

Yep. It's just a (weird) way of saying "we know whether it's NULL or not". Maybe it's worth adding a helper function (in another PR) to make it clearer, since the meaning is super subtle.

Python/optimizer_bytecodes.c Outdated Show resolved Hide resolved
Python/optimizer_bytecodes.c Outdated Show resolved Hide resolved
// isinstance(obj, cls) where both obj and cls have known types
// We can deduce either True or False
PyTypeObject *inst_type = sym_get_type(inst_sym);
if (sym_matches_type(inst_sym, cls) || PyType_IsSubtype(inst_type, cls)) {
Copy link
Member

Choose a reason for hiding this comment

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

Can you add a comment to that effect? :)

Comment on lines 911 to 925
}
else {
// isinstance(obj, cls) where obj has unknown type
res = sym_new_type(ctx, &PyBool_Type);
}
}
else {
// isinstance(obj, cls) where cls has unknown type
res = sym_new_type(ctx, &PyBool_Type);
}
}
else {
res = sym_new_type(ctx, &PyBool_Type);
}
}
Copy link
Member

Choose a reason for hiding this comment

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

You can avoid all of this repetition by doing an unconditional res = sym_new_type(ctx, &PyBool_Type); at the top, and using sym_set_const(ctx, ...) to narrow it when possible.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yup that is way better, updated!

@bedevere-app
Copy link

bedevere-app bot commented May 2, 2025

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@tomasr8
Copy link
Member Author

tomasr8 commented May 3, 2025

(Marking as draft until #133339 is merged which will let us simplify the oparg logic)

@tomasr8
Copy link
Member Author

tomasr8 commented May 9, 2025

I think I addressed all your points. I also added the test you suggested. I'm planning to add support for tuples (e.g. isinstance(foo, (int, str)) in a followup so for now it just supports single types.

@tomasr8 tomasr8 marked this pull request as ready for review May 9, 2025 20:46
@tomasr8 tomasr8 requested a review from brandtbucher May 9, 2025 20:47
Copy link
Member

@brandtbucher brandtbucher left a comment

Choose a reason for hiding this comment

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

Thanks! Just one suggestion, then we can land it.

Python/optimizer_bytecodes.c Outdated Show resolved Hide resolved
@github-project-automation github-project-automation bot moved this from Todo to In Progress in Sprint 2024 May 19, 2025
tomasr8 and others added 3 commits May 19, 2025 15:37
Co-authored-by: Brandt Bucher <brandtbucher@gmail.com>
@Fidget-Spinner
Copy link
Member

This LGTM. A side note: on PyPy, they can actually narrow isinstance(x, cls) to subtype of cls or even better. I wonder if we can do that? Not sure if it's safe to do so though due to subclassing rules and all that.

@brandtbucher
Copy link
Member

Yeah, could be cool. It's not really useful to us right now, since all of our guards are against exact types/versions, not many subclass checks.

@brandtbucher
Copy link
Member

CI failures are unrelated.

@brandtbucher brandtbucher merged commit 8d490b3 into python:main May 19, 2025
44 of 54 checks passed
@github-project-automation github-project-automation bot moved this from In Progress to Done in Sprint 2024 May 19, 2025
@tomasr8 tomasr8 deleted the jit-isinstance branch May 19, 2025 17:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.