http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52255
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-15
11:47:15 UTC ---
The problem is that lsm doesn't cleanup unnecessary VOP PHI after changing:
<bb 5>:
# b.2_21 = PHI <b.3_10(10), b.2_19(8)>
# .MEM_22 = PHI <.MEM_18(10), .MEM_16(8)>
# prephitmp.8_6 = PHI <D.1721_8(10), pretmp.7_1(8)>
D.1720_7 = prephitmp.8_6;
D.1721_8 = D.1720_7 | 1;
# .MEM_17 = VDEF <.MEM_22>
c[0] = D.1721_8;
b.3_10 = b.2_21 + 1;
# .MEM_18 = VDEF <.MEM_17>
b = b.3_10;
if (b.3_10 != 0)
goto <bb 10>;
else
goto <bb 9>;
<bb 10>:
goto <bb 5>;
into:
# VUSE <.MEM_17>
pretmp.7_1 = c[0];
# VUSE <.MEM_17>
c_I_lsm.9_12 = c[0];
# VUSE <.MEM_17>
b_lsm.10_11 = b;
<bb 5>:
# b.2_21 = PHI <b.3_10(10), b.2_19(8)>
# .MEM_22 = PHI <.MEM_22(10), .MEM_17(8)>
# prephitmp.8_6 = PHI <D.1721_8(10), pretmp.7_1(8)>
D.1720_7 = prephitmp.8_6;
D.1721_8 = D.1720_7 | 1;
c_I_lsm.9_24 = D.1721_8;
b.3_10 = b.2_21 + 1;
b_lsm.10_28 = b.3_10;
if (b.3_10 != 0)
goto <bb 10>;
else
goto <bb 12>;
<bb 12>:
# c_I_lsm.9_32 = PHI <c_I_lsm.9_24(5)>
# b_lsm.10_33 = PHI <b_lsm.10_28(5)>
# .MEM_29 = VDEF <.MEM_22>
c[0] = c_I_lsm.9_32;
# .MEM_30 = VDEF <.MEM_29>
b = b_lsm.10_33;
goto <bb 9>;
<bb 10>:
goto <bb 5>;
and there is no dom/phicprop pass in between lim1 and vect that would clean
this mess up (with -O3 -fno-tree-vectorize first dom2 changes that
# .MEM_22 = PHI <.MEM_22(10), .MEM_17(8)>
into
# .MEM_22 = PHI <.MEM_17(10), .MEM_17(8)>
and then phicprop removes it, but e.g. with -O3 -fno-tree-vectorize
-fno-tree-dominator-opts it survives until *.optimized dump). The vectorizer
then ignores virtual PHIs, assuming everything will be handled well by the data
ref analysis and adjustments to the stores in the loop. Which works if the
loop has any stores, because then the stores will have their vdefs renamed, but
if the loop doesn't have any stores, we end up with the verification ICE here.
I think the vectorizer can't rely on these unnecessary virtual PHIs not being
present, so either it could give up on them, or at least for the simple cases
(like this when the virtual PHI on loop->header bb uses itself and some .MEM
from before the loop) could be handled by just propagating the .MEM from before
the loop into all the uses of this vdef.
