René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"`TO_BOOL_INT` repeatedly misses for non-compact exact integers","articleBody":"# Feature or enhancement\n\n### Proposal:\n\n## Versions\n\nCPython 3.15.0b4, Ubuntu 24.04.4 LTS, gcc 13.3.0\n\n## Enhancement\n\nI noticed that the specialization function for `TO_BOOL` and the guard used by `TO_BOOL_INT` accept different sets of integers.\n\n[`_Py_Specialize_ToBool()`](https://github.com/python/cpython/blob/1d90627f1660253b30e5efc2ca092a6231737993/Python/specialize.c#L2842-L2855) selects `TO_BOOL_INT` for any exact integer:\n\n```\nif (PyLong_CheckExact(value)) {\n    specialized_op = TO_BOOL_INT;\n    goto success;\n}\n```\n\nHowever, the [`TO_BOOL_INT` macro](https://github.com/python/cpython/blob/1d90627f1660253b30e5efc2ca092a6231737993/Python/bytecodes.c#L520-L529) uses `_GUARD_TOS_INT`, and that requires the integer to be compact:\n\n```\nop(_GUARD_TOS_INT, (value -- value)) {\n    PyObject *value_o = PyStackRef_AsPyObjectBorrow(value);\n    EXIT_IF(!_PyLong_CheckExactAndCompact(value_o));\n}\n```\n\nAs a result, a **non-compact exact integer** can cause `TO_BOOL_INT` to be selected and then immediately miss its guard. \n\nThis mismatch appears to have been introduced by [GH-143759](https://github.com/python/cpython/pull/143759). Before the refactoring, [`TO_BOOL_INT`](https://github.com/python/cpython/blob/66e1399311c17684c6e26f5d9d9603fbd0717d0d/Python/bytecodes.c#L491-L504) had its own `PyLong_CheckExact()` guard. The refactoring replaced it with a macro using the shared `_GUARD_TOS_INT`, whose domain is narrower.\n\nI see two alternative ways to fix this.\n\n## Option 1: narrow the specialization function\n\nOne option would be to change the integer check in `_Py_Specialize_ToBool()` so that it agrees with the existing guard:\n\n```\nif (_PyLong_CheckExactAndCompact(value)) {\n    specialized_op = TO_BOOL_INT;\n    goto success;\n}\n```\n\nWith this change, non-compact integers remain on the generic `TO_BOOL` path instead of repeatedly entering and missing `TO_BOOL_INT`.\n\nMy main concern with this option was whether the additional compactness check in the specialization function could regress the common case (compact int), so I benchmarked both compact and non-compact integers.\n\nThe benchmark target contained 100 `TO_BOOL` sites and was warmed up before each measurement:\n\n```\nstart = time.perf_counter_ns()\nfor _ in range(10_000):\n    target(value)\nelapsed = time.perf_counter_ns() - start\n```\n\nPositive values mean that the patched build was faster:\n\n| Version      | Input                 | Performance change                    |\n| ------------ | --------------------- | ------------------------------------- |\n| CPython 3.15 | non-compact exact int | +2.21% (95% CI: +1.64% to +2.86%) |\n| CPython 3.15 | compact exact int     | +0.31% (95% CI: −0.15% to +0.70%)     |\n| CPython main | non-compact exact int | +4.03% (95% CI: +1.43% to +7.10%) |\n| CPython main | compact exact int     | −0.23% (95% CI: −0.50% to +0.07%)     |\n\nThe non-compact case improved because it no longer repeatedly enters and misses `TO_BOOL_INT`. For compact integers, both confidence intervals include zero, so I did not find evidence that the stronger specialization check causes a regression.\n\n## Option 2: give `TO_BOOL_INT` an exact-int guard\n\nThe other option is to keep `_Py_Specialize_ToBool()` unchanged and add a guard that checks exact type without requiring compactness:\n\n```\nop(_GUARD_TOS_EXACT_INT, (value -- value)) {\n    PyObject *value_o = PyStackRef_AsPyObjectBorrow(value);\n    EXIT_IF(!PyLong_CheckExact(value_o));\n}\n```\n\nThe `TO_BOOL_INT` macro would then use the new guard:\n\n```\nmacro(TO_BOOL_INT) =\n    _GUARD_TOS_EXACT_INT +\n    unused/1 +\n    unused/2 +\n    _TO_BOOL_INT +\n    _POP_TOP_INT;\n```\n\nThis would restore the specialization domain from before GH-143759.\n\n---\n\nI am not sure which of these two options is preferable, but the current mismatch seems worth fixing, so I am opening this issue to get feedback on which direction would be better.\n\n### Has this already been discussed elsewhere?\n\nNo response given\n\n### Links to previous discussion of this feature:\n\n_No response_\n\n\u003c!-- gh-linked-prs -->\n### Linked PRs\n* gh-155531\n* gh-155699\n* gh-155700\n\u003c!-- /gh-linked-prs -->\n","author":{"url":"https://github.com/marinelay","@type":"Person","name":"marinelay"},"datePublished":"2026-08-10T12:45:58Z","url":"https://github.com/python/cpython/issues/155486"}