Uh, it is my bug.

-     minsize = (minsize | PyDict_MINSIZE) - 1; 
+     minsize = (minsize - 1) | (PyDict_MINSIZE - 1);

Thanks @methane for catching this:

-     minsize = (minsize | PyDict_MINSIZE) - 1; 
+     minsize = (minsize - 1) | (PyDict_MINSIZE - 1);

With that change, you can also simplify the return statement:

-     return _Py_bit_length(minsize | (PyDict_MINSIZE-1));
+     return _Py_bit_length(minsize);

Suggestion: for clarity you might instead write

minsize = PY_MAX(minsize, PyDict_MINSIZE) - 1;
return _Py_bit_length(minsize);

This makes the lower bound explicit, reads more directly at a glance, and the performance difference (if any) should be negligible. The PY_MAX variant even “works” for minsize <= 0, although zero or negative sizes aren’t expected in practice.

Sorry, I was wrong. (minsize - 1) | (PyDict_MINSIZE - 1) is not correct when minsize=0.

Py_MAX() uses conditional move on both of arm64 and amd64.

Well, you were correct to say I was wrong to assume the performance difference is necessarily negligible in this context. I’m going to look more closely into assembly-level costs. But yeah, Py_MAX() is needed for when minsize == 0.