On 7/14/2026 2:30 AM, Richard Biener wrote:
On Wed, Jul 1, 2026 at 2:31 PM Nguyen Tran <[email protected]> wrote:
Thanks Richard.
On point 1 (get_precision on the int_range): I looked into this, and it
does not give the narrowed precision. irange has no get_precision ();
the only one is irange_bitmask::get_precision (), which returns the
mask's wide_int width, that is, the type precision (32 for int), not the
number of bits the values actually occupy. The current computation
instead derives the precision the values need (for example 20 when the
dividend lies in [0, 1000000]), which is what choose_multiplier takes.
On point 2 (passing a value_range object to expand_divmod): I would
prefer to keep the int precision here. The multiply-shift narrowing
uses only the precision: choose_multiplier takes an int precision, and
once that number is known the lower bound, the sign and the exact
endpoints play no part in the computation. Passing the whole range
object would give the callee more than it uses, to arrive at the same
single number it needs today.
The range object would help only a different job, the {1, power-of-two}
work you mentioned, which is not part of this patch. So I would prefer
to keep the int and let that work decide for itself how it wants the
range, rather than add a heavier parameter here that this optimization
does not need.
This patch is small and self-contained, and it is already bootstrapped
and regression-tested, so I would prefer to keep it as it is. Would
that work?
Fair enough. Note I'm not familiar enough with the code paths to
review the rest, I hope Jeff will chime in.
Yea, it looks quite sensible. It might have some conflict with
Hongtao's in-flight work to specialize paths when the divisor has a two
entry range with one value being 2^n. If they end up conflicting in the
cases they want to improve, we'll have to figure out which to
prioritize, but I'm inclined to ACK Nguyen's patch now unless there was
something you're particularly worried about.
jeff
