-
-
Notifications
You must be signed in to change notification settings - Fork 33.2k
GH-130415: Use boolean guards to narrow types to values in the JIT #130659
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
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
|
|
||
| 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 ofxbased on its type. Currently, it's only implemented for booleans, but I'm working with a few people to open PRs to narrowintandstrvalues as well.(The diff looks much worse than it is, since this requires adding
ctxparameters to a couple of helper functions that are used everywhere. The "real" changes inoptimizer_bytecodes.care limited to_GUARD_IS_FALSE_POP,_GUARD_IS_NONE_POP,_GUARD_IS_TRUE_POP,_TO_BOOL,_TO_BOOL_BOOL, and_UNARY_NOT.