On Thursday, 27 November 2025 01:38:37 Pacific Standard Time David Brown via
Std-Proposals wrote:
> Thiago's point (assuming I understand him correctly) - which I agree
> with - is that in a good implementation of _BitInt, the compiler will
> use such specialised implementations for _BitInt when the size is a
> power of 2 (128 in particular). The size of a _BitInt is known at
> compile time, so the compiler can generate slow, general code for
> _BitInt(255) and _BitInt(257) and then fast code for _BitInt(256).

While I expect a fast"er" implementation for powers of 2, that wasn't my
argument and I also don't have a specific of how fast is fast"er".

My argument was *specifically* for _BitInt(XX) and intXX_t: the performance
should be exactly the same if there is a standard or extended integer type
with that exact size.

However slow that is. In other words, it doesn't *have* to be fast at all. It
can be unbearably slow for 128 bits, for example, starting with the calling
convention: two 128-bit factors to a multiplication are 8 32-bit parameter
slots, which is more than any 32-bit platform dedicates for passing in
registers anyway (even old 32-bit SPARC with its fixed-window rotating register
stack only passed 6 arguments in registers).

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.