I hesitate to come back to this thread, because as Raymond says it's consumed a lot of time already.  But I think this point is of broader interest than the specific few lines we've been discussing:

> When small integer are disabled at compilation time (NSMALLPOSINTS=0 and  a NSMALLNEGINTS=0), I suggest to remove code related to small integers. IMHO CHECK_SMALL_INT() macro is a good practical solution for that.

Victor, can you be more specific about the problem this is solving? I think the existing code in master really doesn't leave any problems in place that CHECK_SMALL_INT solves.

In master (as of 2702638ea), here's the code that CHECK_SMALL_INT would replace:

    if (IS_SMALL_INT(ival)) {
        return get_small_int((sdigit)ival);
    }

When NSMALLPOSINTS=0 and NSMALLNEGINTS=0 , this expands in the preprocessor to the equivalent of:

    if (0) {
        return (Py_UNREACHABLE(), NULL);
    }

(Specifically, it expands to whatever that expands to, since Py_UNREACHABLE and possibly NULL are also macros.)

A compiler that's attempting to do any significant optimization at all has to be able to discard code that's inside `if (0)`; dead-code elimination is a necessary primitive for lots of other optimizations.

(And at a quick empirical sanity-check: gcc, clang, and msvc all do so at any optimization setting other than "disabled".  In fact gcc and clang do so even with optimizations disabled.)


You made the case very nicely above that macros are evil.  The IS_SMALL_INT macro is fairly mild, and it has a performance benefit on some platforms to justify it.  But CHECK_SMALL_INT causes a return from the enclosing function, which seems quite high on the "evil macro" scale.