https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103359
--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> ---
This is an artifact of rangers hybrid optimistic/pessimistic approach.
We optimistically assume things are UNDEFINED until we actually have to resolve
them.
The code at the end of FRE is not representative to what we see in EVRP as the
loop code has inserted some PHI copies:
<bb 8> :
# h_7 = PHI <4(2), 1(7)>
<bb 13> :
# h_18 = PHI <h_7(8), h_22(14)>
We have to resolve h_22 on the back edge, and there ends up being a series of
PHIs, and we commit to VARYING before we fully resolve the cycle:
<bb 4> :
# h_22 = PHI <h_10(3)>
<bb 5> :
# h_20 = PHI <h_22(4)>
<bb 12> :
# h_10 = PHI <h_18(13), h_10(15)>
We currently have code to "ignore" arguments that are the same as the def,
because they provide no new info, so when processing something like:
# h_10 = PHI <4(2), h_10(3), h_10(4), 1(7)>
we still come up with [1,1][[4,4]
I notice that when looking at the PHI coming from the back edge:
Equivalence set : [h_10, h_18, h_22]
<bb 4> :
# h_22 = PHI <h_10(3)>
that h_18 is in the equivalency set of h_22 at this point...
I am experimenting with using that information to also decide that since h_22
and h_18 are equivalent on that backedge, that we can avoid using h_22 as well.
which means h_18 and h_7 will be equivalent, and evaluate to [1,1][4,4]. and
then we eliminate the store to C like we did before.
stay tuned.
