There are probably more efficient ways to implement some of these checks (e.g. for a "add two signed integers", you can do the math as unsigned and check if the sign bit for the inputs match the result's sign bit), but this is a good start.

For instance, this untested piece of code:

bool add_int_overflow(int a, int b, int *r)
{
        unsigned int ua = (unsigned int)a;
        unsigned int ub = (unsigned int)b;
        unsigned int ur = ua + ub;
        *r = (int)ur;
        return ua & ub & ur & 0x80000000u;
}

Leverages the fact that & is commutative and that the pipeline won't be stalled waiting for a few different branches like in the portable code from that header. Generated code is similar in both MSVC and GCC, although GCC and Clang will have the builtins that will use things like JA, JO, or SETO on x86 and whatnot.

Instead of reasoning on C source code, it's better to watch the compiled assembly, since the compiler may apply various optimizations.
(also, IIRC psnip tries to use custom intrinsics rather than compatibility code by default)

I know. I looked at the code and saw how it's generated by MSVC on Godbolt. It's not as efficient as the snippet above (which is branchless/makes better use of a CPU's pipeline).

For GCC/Clang we can of course use the intrinsics (and psnip does define them -- even if undefined behavior as it's defining things beginning with two underscores -- for compilers that do not support these intrinsics, so if you include the header, you can just use the GCC/Clang intrinsics and it should work).

Best thing to do here, IMO, is to send a pull request to psnip implementing better overflow checking, and use that.

Yeah, this is something I can take a look after finishing the thing I'm working on.

Yes, I've got quite a bit of changes in my local tree already.

?

I'm trying to get an update.

Opened a draft PR with the changes in the cpython repository: python/cpython#31595

This is a draft because I still haven't finished going through every function in longobject.cyet (there are a few of those), and I still haven't even compiled/tested this yet because I need to get everything ported over to the new representation before trying to start the interpreter.

At this point I haven't implemented what @cfbolz mentioned (having multiple implementations for "long+int", "long*int", etc); I don't think that, at this point, this is going to be an issue. This can be improved later if we find that the workloads we care about would be improved with this additional overhead.

I would appreciate feedback.

when we started this scheme, we added the extra functions as a second step (much) later. at first, all our long+int operations converted the int to a long before calling the actual logic. so maybe the work in CPython could be split up in that way as well.

Why would you have both PyLongObject and PyIntObject? The latter seems sufficient.

We'd need to add PyIntObject before removing PyLongObject, so there would be some overlap, if we want to avoid giant changes.

I've been poking at other objects with multiple representations (like the unicode object), and I'm seeing this pattern of using multiple structs quite a bit. I kinda like this and I'll take a stab at doing this for integers this week.

I took a closer look at this suggestion, and I'm not sure about some things:

1. We pay for a single digit even if we're not using it, because it's always part of the union. It's only sizeof(digit), but it adds up, and if we're going through all this trouble, let's get this right from the get go.

2. Still on the topic of the digit array, I'm not sure about the legality of that as a flexible member within the suggested union in PyIntObject. C99 is too vague on this. I'm inclined to say it's fine but I need to look deeper in the standard to be at ease with this construction. However, see next point.

3. I do like having a PyLongValue, but because of (1), I'm not sure if it's the right way to go. Using type-punning, and having the functions in longmath.c take PyLongObjects instead (and asserting that they are, in fact, long objects) seems to me to be a better option, especially if (1) is considered. Something like this:

typedef struct _ {
    HEAD
    uintptr_t value;  /* unsigned to avoid implementation-defined behavior for bitwise ops */
} PyIntObject;

typedef struct _ {
    PyIntObject _base;
    digit digits[1];
} PyLongObject;

4. Minor point related to (3): with the proposed structs, the filename longmath.c doesn't make much sense anymore, as it wouldn't operate with PyLongValues anymore. It should be named something like longobject_bignum.c or something of the sort.

5. A disadvantage of using the type-punning method, however, is that with the "union method", code in longmath.c wouldn't need to worry about reference counts -- especially for all those temporarily "elongated" values. I'm still thinking about this (it's one of the reasons I like PyLongValue).

6. In the last code snippet (depicting a mocked-up int_add()), there's just one temp value, that is reused for both calls to as_long_value(). If I understood correctly, as_long_value() would be as close as possible to a no-op if the PyIntObject was already long, and use the scratch space provided in the temp variable to "elongate" the value. Is this just a typo (i.e. you intended for it to be two distinct temporary values), or is there something I'm missing here?

7. Although I'm positive it'll be fine, the declaration and use of PyLongValue3 seems a bit shady: digits is of type digit[1] in PyLongValue, and of type digit[3] in PyLongValue3. It's not clear, from my understanding of the C99 standard, that both arrays would be compatible to the point that you could cast a PyLongValue3 to point to a PyLongValue. (See 6.2.7.1 and 6.2.7.3.)

Although none of these points are going to block me, clarifying some of them will help us align expectations. (Or at least explain why the code ended up being the way it'll be once I'm finished.)

Clearly there's more than one way to skin this particular cat. I had always thought that the main point of the exercise was to avoid the digit array in the common case that the value fits (comfortably) in the size field, so we would need only 24 bytes for a medium-sized integer, rather than 28 (which presumably rounds up to 32). If the previous proposal doesn't do that, I think we need to revise it. (I'm not hopeful that we'll see a significant gain in speed after all is said and done, at least not until we introduce opcode specializations for short-to-medium sized integers.)

I wouldn't worry too much about the filename, but I have a (mild) objection against something as long and cumbersome as longobject_bignum.c. (Honestly I don't see much reason to split things into multiple files at this point.)

Regarding the C standard, I have a feeling that we already are violating the strictest possible implementation in many other places in our code. And I wouldn't assume the compilers are perverse. C does have some rules about structs with similar items being laid out similarly, and I think we can trust that rule quite a bit -- even in unions.