https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Robin Dapp from comment #4)
> Yes, the vectorization looks ok. The extracted live values are not used
> afterwards and therefore the whole vectorized loop is being thrown away.
> Then we do one iteration of the epilogue loop, inverting the original c and
> end up with -8 instead of 8. This is pretty similar to what's happening in
> the related PR.
>
> We properly populate the phi in question in
> slpeel_update_phi_nodes_for_guard1:
>
> c_lsm.7_64 = PHI <_56(23), pretmp_34(17)>
>
> but vect_update_ivs_after_vectorizer changes that into
>
> c_lsm.7_64 = PHI <pretmp_34(17), pretmp_34(17)>.
>
> Just as a test, commenting out
>
> if (!LOOP_VINFO_EARLY_BREAKS_VECT_PEELED (loop_vinfo))
> vect_update_ivs_after_vectorizer (loop_vinfo, niters_vector_mult_vf,
> update_e);
>
> at least makes us keep the VEC_EXTRACT and not fail anymore.
I'll note that on x86_64 we do the same and not fail the testcase. x86
cannot use partial vectors because we don't implement EXTRACT_LAST,
so that might be the "key" to the failure (partial vectors). And we
might need to "fail" vectorization of the special inductions when
using them?
This might be also out-of-sync handling of which ones we handle with
vect_update_ivs_after_vectorizer and which ones with
vectorizable_live_operation - as indeed we do generate the EXTRACT_LAST here.
