On Mon, Jul 20, 2026 at 6:28 PM Jeffrey Law <[email protected]> wrote: > > > > 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.
I was only wondering about the API change generalization. Richard. > > jeff
