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

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?

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?

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.

Richard.

> Andrew