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

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.

Andrew