Widen specialized int fast paths to full int64 range

[KRRT7]

This work widens the interpreter’s specialized int fast paths (tier-2 / uop execution) from the compact-only range to the full int64_t range.

It also fixes follow-up correctness issues in the widened specialized paths for non-compact exact PyLongObjects and on 15-bit builds.

Scope:

• widen specialized integer add/subtract/multiply fast paths to operate across the full int64_t range
• accept exact int operands that fit in int64_t, including non-compact PyLongObjects
• keep specialized in-place mutation compact-only and fall back safely for non-compact inputs
• handle widened integer compare without compact-only assumptions
• construct widened arithmetic results with PyLong_FromInt64() so 15-bit builds do not narrow through stwodigits
• add regression coverage for widened operations, non-compact exact ints, boundary cases, and overflow fallback
• add benchmark scripts for measuring widened specialized integer fast-path performance

Linked PRs

• gh-150424: Widen specialized int fast paths to full int64 range #150425

[picnixz]

Do we support 15-bit builds actually?

[picnixz]

In addition, please clearly clarify the issue. The issue description is obscure and looks like a simple LLM report. In particular, please read https://devguide.python.org/getting-started/generative-ai/ first and share benchmarks if they improve.

[markshannon]

If you want to improve int performance then take a look at #101291

[KRRT7]

@markshannon Thanks! I had looked for something like that issue but hadn't found it for whatever reason, probably because cpython has so many issues.

the work I'm doing #150425, is based off of work already being done in another project I'm involved in, as I had tried to explain (and show) in that other PR, gh-150424 was a draft and still a WIP so what was being seen, was not the completed version.

right now it's in a much better state and has benchmarks, I've had some guidance from @Fidget-Spinner whilst working on this and plan to do some more benchmarking and correctness testing locally before reopening.

[KRRT7]

In particular, please read https://devguide.python.org/getting-started/generative-ai/

I believe I had in the PR already stated that I did read that.

The issue description is obscure and looks like a simple LLM report.

None of the templates have anything for performance related "issues" that I felt I could open up with.
https://github.com/python/cpython/tree/main/.github/ISSUE_TEMPLATE/

in the absence of that, a simple, straightforward body was what I felt best. and I've edited It multiple times as I kept seeing room for improvement.

[KRRT7]

I just did a deep search thru issues and PRs and i found these prior arts where i feel that my current work builds on top off of:

• Restore (or beat) Python 2 performance for arithmetic operations on ints that fit into a single word #101291 (and its linked PRs): compact int representation + APIs that enabled the existing fast paths (lv_tag/compact machinery, etc.). My changes don’t propose a new int layout; they extend the JIT’s current “compact-only” integer arithmetic specialization to cover exact int operands that still fit in int64_t (including non-compact PyLongObjects), with conservative overflow detection and fallback.
• [C API] Add PyLong_FromInt64() and PyLong_ToInt64() #120389 / PR gh-120389: Add PyLong_FromInt64() and PyLong_AsInt64() #120390: adds PyLong_FromInt64() / PyLong_AsInt64(), which I use for constructing widened results and for conversion/fallback boundaries.
• The C-API for Python to C integer conversion is, to be frank, a mess. #102471 / PR gh-102471, PEP 757: Add PyLong import and export API #121339 (PEP 757 import/export + PyLong_AsNativeBytes ecosystem): broader context on improving and standardizing int↔C integer conversions.
• issue Top-of-stack caching in the JIT #135379 / PR GH-135379: Top of stack caching for the JIT. #135465 (+ follow-ups like PR python/cpython#135707): precedent for targeted JIT-only performance work, including the “compact check” plumbing story.
• issue Add freelist for compact int objects #126868 / PR gh-126868: Add freelist for compact int objects #126865: continued investment in compact-int fast paths (freelist for compact ints).