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

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).

>
> So although it isnt awesome to have to do the walk, i didnt think it
> would happen much..  so we can either add the deferred removal mentioned
> above, or I could add a parallel bitfield which marks which blocks there
> are inferred ranges in, and just visit those.
>
>
> >
> > That feels like very bad(TM).
> >
> > Did you think of a global SSA-generation-number that could be checked
> > against one recorded in an equivalence?
> >
> > As all of this is for this early gcc_unreachable () removal it really feels like
> > spending time on a hackish solution there in isloation would make sense?
> well, it mostly went in this direction because i wasn't even aware of
> reset_flow_senstive_info  until recently... when someone tried to use it
> to clear range info... and ranger had no facility to do that at all...
> It seemed like it might b a good idea to be able to handle it.
> >
> > OTOH reset_flow_sensitive_info also expects to clear relations - it is used
> > for example when a definition is moved across a condition formerly guarding it.
>
> relations are all cleared in the patch as well, along with any of
> rangers cached values.. so this would now work if ranger is also involved.
>
> Andrew
>
>