gh-100239: Propagate type info through _BINARY_OP_EXTEND in tier 2 - #148146
gh-100239: Propagate type info through _BINARY_OP_EXTEND in tier 2#148146Fidget-Spinner merged 1 commit into
Conversation
Sorry, something went wrong.
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.
| /* 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; |
There was a problem hiding this comment.
Isn't this always true?
Sorry, something went wrong.
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
Sorry, something went wrong.
| {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}, |
There was a problem hiding this comment.
These can return small int too right? In that case, the result would not be unique
Sorry, something went wrong.
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).
Sorry, something went wrong.
Adds 2 new fields to _PyBinaryOpSpecializationDescr:
The tier 2 optimizer now narrows the result of _BINARY_OP_EXTEND symbol's type via sym_new_type(d->result_type) and wraps it in PyJitRef_MakeUnique when the result_unique field is set, enabling downstream tier2 optimizations. A test verifies that (2 + x) * y with x, y floats uses _BINARY_OP_MULTIPLY_FLOAT_INPLACE and elides _GUARD_NOS_FLOAT. With these changes the calculation of (2 + x) * y is now 35% faster.
The changes have been factored out of #128956.