On Wed, Aug 19, 2026 at 6:57 PM Andrew MacLeod <[email protected]> wrote: > > > 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.
Thanks - I believe "it likely won't happen" isn't a good stance for software development ... Richard. > > Andrew >
