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
