bpo-46841: Fix BINARY_OP's handling of inline caches (GH-31671)

This commit is contained in:
Brandt Bucher 2022-03-04 10:51:27 -08:00 committed by GitHub
parent cedd2473a9
commit c4d2d57eef
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 7 additions and 3 deletions

View File

@ -0,0 +1,2 @@
Fix incorrect handling of inline cache entries when specializing
:opcode:`BINARY_OP`.

View File

@ -2028,8 +2028,9 @@ handle_eval_breaker:
DEOPT_IF(!PyUnicode_CheckExact(left), BINARY_OP);
DEOPT_IF(Py_TYPE(right) != Py_TYPE(left), BINARY_OP);
DEOPT_IF(Py_REFCNT(left) != 2, BINARY_OP);
int next_oparg = _Py_OPARG(*next_instr);
assert(_Py_OPCODE(*next_instr) == STORE_FAST);
_Py_CODEUNIT true_next = next_instr[INLINE_CACHE_ENTRIES_BINARY_OP];
int next_oparg = _Py_OPARG(true_next);
assert(_Py_OPCODE(true_next) == STORE_FAST);
/* In the common case, there are 2 references to the value
* stored in 'variable' when the v = v + ... is performed: one
* on the value stack (in 'v') and one still stored in the

View File

@ -1951,7 +1951,8 @@ _Py_Specialize_BinaryOp(PyObject *lhs, PyObject *rhs, _Py_CODEUNIT *instr,
break;
}
if (PyUnicode_CheckExact(lhs)) {
if (_Py_OPCODE(instr[1]) == STORE_FAST && Py_REFCNT(lhs) == 2) {
_Py_CODEUNIT next = instr[INLINE_CACHE_ENTRIES_BINARY_OP + 1];
if (_Py_OPCODE(next) == STORE_FAST && Py_REFCNT(lhs) == 2) {
*instr = _Py_MAKECODEUNIT(BINARY_OP_INPLACE_ADD_UNICODE,
oparg);
goto success;