https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125501
--- Comment #18 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to [email protected] from comment #16) > 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? Doesn't the if (a4_14 == 0) also dominate the bultin_unreachable tho? so that would still pass I think? the problem is rooted in the fact that the (a4_14 == 0) expression dominates all the uses of a5_16, so we change its value to [1, +INF] , and then later move the expression so the 2 conditions order is change thereby changing the condition under which a5_16 was given that value. I think the only option is to bail in this scenario like VRP does and NOT assign the global value early. Im not sure how to figure out when its safe easily. It'll get assigned in VRP2, if it is safe to do so then.
