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
