--- Comment #4 from amacleod at redhat dot com 2006-10-02 13:56 ---
This is not something out of ssa can resolve on its own.
given this sequence:
# s_2 = PHI s_5(0), s_9(1);
# d_1 = PHI d_6(0), d_10(1);
L0:;
D.1287_8 = MEM[base: d_1];
s_9 = s_2 + D.1287_8; --- s_2 and
--- Comment #5 from amacleod at redhat dot com 2006-10-02 14:01 ---
I guess you can flatten the goto slightly.
this is still something that is not really in the scope of out of ssa. part of
the root of this problem is that the PHI is really just a copy, but the fact
that it remains a
--- Comment #6 from steven at gcc dot gnu dot org 2006-10-02 21:46 ---
Re comment #5: A quick pass to look for these cases and transform those PHIs
into copies at the appropriate place would accomplish the same thing.
That is exactly what I'd expect the out-of-ssa pass to take care of.
--- Comment #7 from amacleod at redhat dot com 2006-10-02 22:13 ---
Its not that you are expecting too much, just in the wrong place from my point
of view :-) Changing the out of ssa algorithm or implementation isnt going to
change this code. It requires changing the code out of ssa
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-30 09:25 ---
Typically something I'd hope the new out-of-ssa pass would improve.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27986
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-03 07:18 ---
Confirmed, Out of SSA should have created split the variable's range so that
the conflicting parts are not changed inside the loop.
before Out of SSA:
# s_2 = PHI s_5(0), s_9(1);
# d_1 = PHI d_6(0), d_10(1);
