-
-
Notifications
You must be signed in to change notification settings - Fork 31.4k
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
GH-130415: Use boolean guards to narrow types to values in the JIT #130659
GH-130415: Use boolean guards to narrow types to values in the JIT #130659
Conversation
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.
Looks correct, but I'm not keen on the names. Naming is hard, so I don't have much better names.
At least "truthy", rather than just "truth", would suggest Python bool(x)
semantics.
Maybe "to_bool"?
Also, can you add some C tests to Python/optimizer_symbols.c for the various operations?
Python/optimizer_bytecodes.c
Outdated
@@ -430,6 +431,11 @@ dummy_func(void) { | |||
} | |||
} | |||
|
|||
op(_UNARY_NOT, (value -- res)) { | |||
sym_set_type(value, &PyBool_Type); | |||
res = sym_new_truth(ctx, value, true); |
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.
From casual reading, this looks like an error as the true
argument implies that this has the value True
.
Maybe rename sym_new_truth
as sym_from_truthiness
and have false
as the argument for NOT
and true
as the argument for TO_BOOL
?
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.
Or symbolic consts, like TO_BOOL
and INVERT
?
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.
I'd like to avoid a double-negative in the arg name (since inverting it from its current meaning would mean something like "not not"). What if I make it an int and use 0
and 1
instead? I feel like a big part of the friction in reading this is the use of true
and false
as arguments.
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.
0 /1 or false/true doesn't matter. Good symbolic names is what is needed.
Maybe even use two different functions with different names?
I agree the naming is hard. How about |
We can think ahead with the naming too. Soon we’ll have equality and identity as symbols, and we’ll probably want something reasonably consistent (“truth”, “equality”, and “identity” were the planned names). |
Maybe "truthiness" rather than "truthy" then? |
I've heard "truthiness" used to describe the boolean value of a non-boolean in a test. Probably more in a javascript context, but for Python as well. |
Sounds good, thanks for the suggestions. |
|
This adds a symbolic "truth" type to the JIT optimizer, allowing tests like
if not x: ...
to narrow the value ofx
based on its type. Currently, it's only implemented for booleans, but I'm working with a few people to open PRs to narrowint
andstr
values as well.(The diff looks much worse than it is, since this requires adding
ctx
parameters to a couple of helper functions that are used everywhere. The "real" changes inoptimizer_bytecodes.c
are limited to_GUARD_IS_FALSE_POP
,_GUARD_IS_NONE_POP
,_GUARD_IS_TRUE_POP
,_TO_BOOL
,_TO_BOOL_BOOL
, and_UNARY_NOT
.