Re: [COMMITTED] PR tree-optimization/126856 - Provide a range_info reset method.

On Wed, Aug 19, 2026 at 6:57 PM Andrew MacLeod <[email protected]> wrote:
>
>
> On 8/19/26 12:41, Andrea Pinski wrote:
> > On Wed, Aug 19, 2026 at 7:14 AM Andrew MacLeod <[email protected]> wrote:
> >>
> >> On 8/19/26 09:37, Richard Biener wrote:
> >>> On Wed, Aug 19, 2026 at 1:16 AM Andrew MacLeod <[email protected]> wrote:
> >>>> My patch for 126329 allows early removal of builtin_unreachable to
> >>>> proceed by replacing dead statements with an assignment to zero instead
> >>>> of removing them.
> >>>>
> >>>> In theory that was safe because there were no uses of the name in the
> >>>> IL.   The fallout was that if there was an existing equivalence or
> >>>> relation with some other ssa name, this  made those equivalences and
> >>>> relations now relative to [0, 0].  oops.
> >>>>
> >>>> I looked at a few options, and they all seemed a bit hacky.. In the end,
> >>>> Ive provided a way to remove all relevant information about a range from
> >>>> all the various components... Ranger, the relation oracle, the inferred
> >>>> range oracle, and gori.   Although this might seem like a bit of
> >>>> overkill, it fills a gap that was uncovered a few months ago with
> >>>> reset_flow_sensitive_info.
> >>>>
> >>>> There are uses of reset_flow_sensitive_info (name) sprinkled around the
> >>>> compiler which currently kills just  the SSA_NAME_RANGE_INFO for an SSA
> >>>> NAME.  It won't affect ranger or any other component, and this may lead
> >>>> to behaviour the developer is not expecting.
> >>>>
> >>>> With this patch, a range_query object now has a reset_range_info ()
> >>>> which is called by reset_flow_sensitive_info () and corrects this
> >>>> situation.  It will clear any range info from the current range object,
> >>>> as well as the various oracles.. relations, inferred ranges, and gori.
> >>>> Its a bit heavy handed but does a full job.  I had considered just
> >>>> clearing some of the cache flags, but if the ssa_name were to be used
> >>>> again (and other use cases may expect that) some of the old relations
> >>>> would have popped back into existence.   This now expunges all of them.
> >>>> Overall compile time building gcc is actually a wash.
> >>>>
> >>>> The DCE fix for this PR now simply calls reset_flow_sensitive_info on
> >>>> the ssa-name when it rewrites the statement to be an assignment of 0.
> >>>> This clears all the information that may cause issues, and life is
> >>>> hopefully good again.
> >>>>
> >>>> Bootstraps on x86_64-pc-linux-gnu  with no regressions.   Pushed.
> >>> So
> >>>
> >>> +void
> >>> +infer_range_manager::clear(tree name)
> >>> +{
> >>> ...
> >>> +  // Check each basic block for an inferred range.
> >>> +  basic_block bb;
> >>> +  FOR_EACH_BB_FN (bb, cfun)
> >>> +    {
> >>>
> >>> ouch.  This means we're possibly walking the CFG num-ssa-names times?
> >>> Can the walk be constrained given the definition point of 'name' at least?
> >> Well, not really num-ssa-names times.  It will only happen for an
> >> ssa-name  if there are registered inferred ranges against that name.  we
> >> could do a dom walk from the def point for each name... i just didnt
> >> think this was actually going to be triggered that often.    We could
> >> also easily defer this by
> >>      a) clearing the 'm_seen' bit for the name, (meaning no queries will
> >> succeed),
> >>      b) setting a new bit  'm_deferred" cleanup for the name, and
> >>      c) if  a new inferred range is registered against it, and 'm_seen"
> >> is false and "m_deferred" is true,  Then go clear them out before
> >> registering a new one.
> >>
> >> That would defer the work until a name is actually cleared and then
> >> reused, and then only when both before and after are having inferred
> >> ranges registered against them.   That would reduce the number of calls
> >> even more.
> >>
> >>      Are there any passes which currently use ranger which also use
> >> "reset_flow_sensitive_range_info"?   If they don't use ranger, none of
> >> this will ever trigger.  My performance runs didn't find much of
> >> anything.     If they do use ranger, then a lot of information has been
> >> broken all along because nothing was every cleared in ranger.
> > Wait I am mixing up two different passes, ifcombine does the
> > save/restore (so does phiopt). But neither turns on the ranger
> > currently.
> > Fowrprop turns on the ranger conditionally (while trying to handle
> > rotates IIRC) but does not do the save/restore.
> > I was thinking about a way to turn on the ranger for phiopt because I
> > have seen opportunities there recently (while mentoring someone;
> > though phiopt first has to move away from creating COND_EXPR with a
> > comparison inside it [unrelated to the problem here]).  Maybe it won't
> > be so bad for phiopt because the save/restores are limited to bb which
> > have only one statement (but soon might be extended to more).
> >
> >>
> Well there is no restore for ranger... it would recalculate whatever it
> needs based on whats in the IL.  If you restore a global value, it will
> begin with that.
>
> I'll look at making the deletes more efficient for future proofing.

Thanks - I believe "it likely won't happen" isn't a good stance for
software development ...

Richard.

>
> Andrew
>