gh-100239: Propagate type info through _BINARY_OP_EXTEND in tier 2#148146
Merged
Fidget-Spinner merged 1 commit intopython:mainfrom Apr 6, 2026
Merged
gh-100239: Propagate type info through _BINARY_OP_EXTEND in tier 2#148146Fidget-Spinner merged 1 commit intopython:mainfrom
Fidget-Spinner merged 1 commit intopython:mainfrom
Conversation
Adds two new fields to _PyBinaryOpSpecializationDescr: - result_type: the static type of the result (or NULL if unknown). - result_unique: nonzero iff `action` always returns a freshly allocated object (not aliased to either operand). The tier 2 optimizer now narrows the result symbol's type via sym_new_type(d->result_type) and wraps it in PyJitRef_MakeUnique when d->result_unique is set. This lets downstream ops elide their operand-type guards and pick inplace variants. For example, (2 + x) * y with x, y floats now compiles to _BINARY_OP_MULTIPLY_FLOAT_INPLACE with _GUARD_NOS_FLOAT eliminated. All existing descriptors populate both fields: long-long bitwise ops produce unique PyLong results, and float/long mixed arithmetic produces unique PyFloat results. A test verifies the inplace-multiply case end-to-end.
Comment on lines
+502
to
+505
| /* Nonzero iff `action` always returns a freshly allocated object (not | ||
| aliased to either operand). Used by the tier 2 optimizer to enable | ||
| inplace follow-up ops. */ | ||
| int result_unique; |
Contributor
Author
There was a problem hiding this comment.
Yes, here it is. In the pr this was factored out from we had more specializations where this would not always be true.
We can remove it here and add back later. I think it would be needed of we use the binary_op_extend as s mechanism for adding more cases to tier 2 without creating more tier 1 opcodes
Fidget-Spinner
approved these changes
Apr 6, 2026
| {NB_INPLACE_OR, compactlongs_guard, compactlongs_or}, | ||
| {NB_INPLACE_AND, compactlongs_guard, compactlongs_and}, | ||
| {NB_INPLACE_XOR, compactlongs_guard, compactlongs_xor}, | ||
| {NB_OR, compactlongs_guard, compactlongs_or, &PyLong_Type, 1}, |
Contributor
There was a problem hiding this comment.
These can return small int too right? In that case, the result would not be unique
Contributor
Author
There was a problem hiding this comment.
The contract is that operations making use of the uniqueness can handle small ints. (The inplace versions of BINARY_ADD_INT handle this for example).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds 2 new fields to
_PyBinaryOpSpecializationDescr:result_type: the static type of the result (orNULL).result_unique: whether the action always returns a freshly allocated object (not aliased to either operand).The tier 2 optimizer now narrows the result of
_BINARY_OP_EXTENDsymbol's type viasym_new_type(d->result_type)and wraps it inPyJitRef_MakeUniquewhen theresult_uniquefield is set, enabling downstream tier2 optimizations. A test verifies that(2 + x) * ywithx,yfloats uses_BINARY_OP_MULTIPLY_FLOAT_INPLACEand elides_GUARD_NOS_FLOAT. With these changes the calculation of(2 + x) * yis now 35% faster.The changes have been factored out of #128956.