On Wed, Apr 12, 2023 at 12:59 PM Jakub Jelinek <ja...@redhat.com> wrote: > > On Wed, Apr 12, 2023 at 11:12:17AM +0200, Richard Biener wrote: > > > 108139 fixed this by not evaluating any equivalences if the equivalence > > > was the LHS. > > > > > > What it missed, was it possible we are calculating the range of a_3. > > > b_2 is not defined in a phi node, so it happily used the equivalence. > > > This PR demonstrates that we can't always use that equivlence either > > > without more context. There can be places in the IL where a_3 is used, > > > but b_2 has moved to a new value within a loop. > > > > I think that's only possible when b_2 flows in via a backedge (from BB3). > > So isn't this all about backedges? Indeed creating equivalences across > > Apparently backedges and undefined phi arg, without that it doesn't seem > to trigger because then it isn't considered equivalent even if the two have > same range. > > > backedges is futile with SSA. I think ranger requires dominators, so > > to have the above scenario - a_3 used after the b_2 definition - requires > > BB3 to be dominated by the a_3 definition which is what you could check. > > Would be nice. > > Though, I'm afraid it still wouldn't fix the PR101912 testcase, because > it has exactly what happens in this PR, undefined phi arg from the > pre-header and uses of the previous iteration's value (i.e. across > backedge).
Well yes, that's what's not allowed. So when the PHI dominates the to-be-equivalenced argument edge src then the equivalence isn't valid because there's a place (that very source block for example) a use of the PHI lhs could appear and where we'd then mixup iterations. > > Jakub >
