On Wed, 14 Jan 2026 at 11:04, Hans Åberg <haberg_1_at_[hidden]> wrote:

>
> > On 14 Jan 2026, at 10:43, Jan Schultke <janschultke_at_[hidden]>
> 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.