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

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.

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