https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125501
--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 3 Jun 2026, amacleod at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125501 > > --- Comment #15 from Andrew Macleod <amacleod at redhat dot com> --- > (In reply to Richard Biener from comment #14) > > (In reply to Andrew Macleod from comment #12) > > > (In reply to Richard Biener from comment #11) > > > > > > > SO I believe it is true that a5_16 is in fact [1, +INF] for all uses > > > within > > > the function. > > > I guess the problem is that in dom2 the order is > > > if (a4_14 == 0) return if (a4_14 == a5_16) > > > IN which case it is true that a5_16 is globally [1, +INF] for all uses. > > > > I think this logic pre-dates the ability to have relations involved. > > Because > > we effectively have if (a5_16 == 0) return; if (a5_16 == 0) unreachable (); > > where you of course cannot make a5_16 != 0 globally. But the > > all_uses_feed_or_dominated_by_stmt does not consider equal-related stmt > > uses. > > > > Do we know sth like "no (in-)equality relations with another name"? I think > > we'd have to assert this here as well. > > We know it for specific names, like is a5_16 related to foo_3, but we do not > have a query like "is a5_16 related to ANY other name". > > I had a WIP for asking for the "nearest" relation to a5_16... which would walk > the dominator structure and return the first relation involving a5_16, but > that > never made it to trunk. I could dig it up... we could then do this > optimization if that routine returned VREL_NONE. I suppose We could have a > specialized version for ==/!=, and a general one for all relations. > > I guess you'd have to ask that question in all_uses_feed_or_dominated_by_stmt > at each use location. > > I can see if I can find the WIP patch.. it was being developed to help a > couple > of other PRs The alternative would be to only do all_uses_feed_or_dominated_by_stmt when we elide the unreachable() call at the same time. Not 100% sure this will fix all possible cases though. Maybe the issue really only appears when the condition we are working on is itself the relation producing stmt? And so we can check for all_uses_feed_or_dominated_by_stmt on both sides of the equality/inequality?
