Dear Richard, Dear Jeffrey, I am writing to follow up on this patch. Could you please let me know its current status?
Thank you, Nguyen On Tue, Jul 21, 2026 at 1:37 AM Jeffrey Law <[email protected]> wrote: > > > On 7/20/2026 11:23 AM, Richard Biener wrote: > > 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. > Ah. I'm not aware of a strong need to plumb the range API down further > right now. I'd kind of prefer to see the range API making a difference > in the synth mult paths first, if it does, then I think we'd look at > plumbing it down so that the divmod path could pass them down into the > synth mult path. I suspect Hongtao's code doesn't need deep plumbing of > the range APIs since (IIRC) he's doing a high level split of the 2^n > path vs the nearby alternate. > > Jeff >
