https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116081
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yeah, that doesn't fix the SHL_INSERT.
@@ -3628,17 +3628,17 @@
t.c:14:21: note: ------>vectorizing phi: i_12 = PHI <i_7(5), 0(12)>
t.c:14:21: note: ------>vectorizing phi: ivtmp_14 = PHI <ivtmp_13(5),
32000(12)>
t.c:14:21: note: ------>vectorizing phi: vectp_in.6_30 = PHI
<vectp_in.6_31(5), &in(12)>
-t.c:14:21: note: ------>vectorizing phi: vect_res_10.13_43 = PHI
<vect_res_6.14_47(5), { 0, ... }(12)>
-t.c:14:21: note: ------>vectorizing phi: vect_res_10.13_44 = PHI
<vect_res_6.14_48(5), { 0, ... }(12)>
+t.c:14:21: note: ------>vectorizing phi: vect_res_10.13_44 = PHI
<vect_res_6.14_48(5), _43(12)>
t.c:14:21: note: ------>vectorizing phi: vect_res_10.13_45 = PHI
<vect_res_6.14_49(5), { 0, ... }(12)>
t.c:14:21: note: ------>vectorizing phi: vect_res_10.13_46 = PHI
<vect_res_6.14_50(5), { 0, ... }(12)>
+t.c:14:21: note: ------>vectorizing phi: vect_res_10.13_47 = PHI
<vect_res_6.14_51(5), { 0, ... }(12)>
so the SHL_INSERT happens in get_initial_defs_for_reduction where we
fail to optimize the case of the neutral op being equal to all elts.
But it's going to be interesting to find that other == or != compare of
types which is certainly there somewhere triggering another path
(the dump difference doesn't give a hint).
