>
> 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?

> 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>?