> On 14 Jan 2026, at 10:43, Jan Schultke <janschultke@googlemail.com> wrote:
>
> Yes, that is how I discovered it was much faster. It is a template, essentially an implementation of div_wide in this proposal:
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3161r4.html#functions.div_wide
>
> LLVM implements it with a loop. I made recursive templates, removing the loop and all multiplications except one per halfword.
>
> Tiago Freire has a copy which might be used for a reference implementation, in case you would like to add requirements that compilers have it, not merely being optional.
>
> If you have an optimization opportunity that LLVM does not take, why don't you make an LLVM PR or bug report instead of a C++ proposal?
The optimizations are not a part of a C++ proposal, clearly, since the standard does not make such statements. There is usually a requirement of at least one fairly efficient implementation, leaving it open for improvements, and that is what I indicated.
The entire motivation for your proposal appears to be that there is a missed optimization in LLVM. If you believe that this is outside the scope of the standard, then you have zero motivation, by your own understanding of the situation. You haven't provided any reason besides performance why an int_mod or mod_int type distinct from _BitInt needs to exist in the language.
The LLVM code is in C, so templates won't help there. They seem happy with what they have.
Whether the compiler backend for some implementation is written in Rust, or C, or JavaScript doesn't provide any motivation for a C++ proposal.
There's no innate reason why a part of the LLVM runtime library being written in C requires a new C++ fundamental type.
>> And if so, why can't the compiler do
>> the same? What is the reason it cannot do the same?
>
> Why don't you ask the compiler or compiler writer? :-)
>
> Why don't we ask you? You're the one arguing there needs to be a mod_int C++ feature, so you're the one who needs to motivate it.
>
> In order to remove the loop, one has to restructure the condition. For a full word implementation, one has to use two's complement features. Then in addition, using the mathematical facts that preliminary division overshoots with at most 2, that the add back step is not needed, and can further be exploited to eliminate a final multiplication.
>
> And why is it innately impossible for LLVM to perform this two's-complement-based and mathematical optimization for unsigned _BitInt(128), unlike for mod_int<128>?
Try to make LLVM transform this traditional 32-64 bit (32-bit word) implementation, using signed integers here below, into a full word 64-bit implementation, using only unsigned types.
https://raw.githubusercontent.com/hcs0/Hackers-Delight/master/divmnu64.c.txt
Dropping a link to some random numerical code doesn't answer the question, and it's not the job of this mailing list to extrapolate proposal motivation from various links you drop in here.