http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57186
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-05-07
CC| |rguenth at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> 2013-05-07
09:02:48 UTC ---
In theory we have the SCCP patch to address at least case #1. It looks
at loop exit PHIs and tries to replace them with the overall effect of
the loop (using SCEV analysis, which is why it fails for loads).
<bb 4>:
# i_15 = PHI <i_10(3), 0(2)>
_4 = (long unsigned int) i_15;
_5 = _4 * 4;
_7 = v_6(D) + _5;
r_9 = *_7;
i_10 = i_15 + 1;
if (i_10 != 64)
goto <bb 3>;
else
goto <bb 5>;
<bb 5>:
# r_20 = PHI <r_9(4)>
the complication with handling the above in existing passes (for example
code sinking) is that the final value of _7 is needed to sink the dependent
computations. So I think what SCCP should do here is look at the
single-use chain from the defs of r_20 and analyze the evolution of
the dependent loop variant SSA names, performing sinking of the dependencies
as well. Conveniently LIM runs before SCCP and performs the necessary
store sinking to allow handling of the last case.
