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

Reply via email to