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

On 8/19/26 03:21, Andrea Pinski wrote:
> On Tue, Aug 18, 2026 at 4:16 PM 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.
> The only problem with this is during forwprop (and other passes), we
> save off the flow sensitive info and then restore it.
> It uses reset_flow_sensitive_info to clear it but we only save off the
> global ranges (or the global pointer data) for that ssa name.
> So now we never restore the equivalents here.

But do those passes that "save" flow information use ranger?  if they 
aren't using ranger, then there are no active oracles or context 
sensitive flow information to be cleared.  Those equivalences and such 
are only for the duration of a pass.

   If they are using ranger, that seems like a problem if they are 
saving information and restoring it but leaving rangers info alone.

> See flow_sensitive_info_storage class in tree-ssanames.cc and its
> usage in tree-ssa-forwprop.cc . So this could cause some performance
> issues with some code paths happening and such.
If ranger isn't active those calls do nothing.
> Thanks,
> Andrea
>
>> Bootstraps on x86_64-pc-linux-gnu  with no regressions.   Pushed.
>>
>> Andrew