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). > > 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 > >
