https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125501
--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> --- > Am 03.06.2026 um 16:40 schrieb amacleod at redhat dot com > <[email protected]>: > > 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. That sounds good. We should only infer global ranges from relations when we then elide it. Richard > > -- > You are receiving this mail because: > You are on the CC list for the bug.
