Get the add-opcodes branch ready to merge upstream.

[gvanrossum]

The branch is here (a bit stale): https://github.com/gvanrossum/cpython/tree/add-opcodes

There's also this PR (also stale): python/cpython#25090

@brandtbucher The note said "convert to issue and assign to Brandt" so that's what I'm doing. But somehow I've forgotten context from our meeting -- do you recall? IIRC someone (@markshannon?) said "actually we should probably do that even though it didn't seem to move the benchmark numbers." But this version seems to only add an ADD_INT opcode, which seems redundant given your work on BINARY_OP. So maybe I'm just making a mess?

• Clean up code
• Run benchmarks (@ericsnowcurrently?)
• Create PR

[markshannon]

Our current stats show that the LOAD_CONST BINARY_OP_ADD_INT pair (which is equivalent to AD_INT) is about 0.6% of the execution count.

So, while there might be some benefit to this, it wouldn't be much.
I'm inclined to abandon this.

[brandtbucher]

I have a branch laying around somewhere. Let me catch it up with main and benchmark to confirm your intuition.

[markshannon]

I assume that this isn't happening.

We should probably implement ADD_INT, if only to shrink the code object size, but let's make a separate issue that.

[brandtbucher]

Update: the benchmarking results are underwhelming.

Branch here, for anyone curious.

[gvanrossum]

Sorry, the thing that Mark and I agreed on wasn't happening was a much older version of this idea (the branch is deleted).

We might actually revive part of it if we get serious about reducing the code object size, since this would remove the need to have small ints in co_consts.

Regarding your branch, maybe the benchmark is slower because it has several conditional branches? I assume in the vast majority of cases where the code says x + 1, x is an int, so at the very least the check for PyLong ought to be first, and probably the float code isn't worth it (or could be done using a specialization).

[brandtbucher]

Good observation! I'll re-run with just the int fast-paths. Maybe if we like the results, we could then explore adding proper specializations.

[brandtbucher]

A little better, but not much.