https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- I think the patch in comment 2 is the correct fix (OK to commit). (In reply to Kewen Lin from comment #4) > (In reply to avieira from comment #3) > > Hi Kewen, > > > > Thanks for the analysis. The param_vect_partial_vector_usage suggestion > > seems valid, but that shouldn't be the root cause. > > > > I would expect an unpredicated V8HI epilogue to fail for a V8HI main loop > > (unless the main loop was unrolled). > > > > That is what the following code in vect_analyze_loop_2 is responsible for: > > /* If we're vectorizing an epilogue loop, the vectorized loop either needs > > to be able to handle fewer than VF scalars, or needs to have a lower VF > > than the main loop. */ > > if (LOOP_VINFO_EPILOGUE_P (loop_vinfo) > > && !LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo) > > && maybe_ge (LOOP_VINFO_VECT_FACTOR (loop_vinfo), > > LOOP_VINFO_VECT_FACTOR (orig_loop_vinfo))) > > return opt_result::failure_at (vect_location, > > "Vectorization factor too high for" > > " epilogue loop.\n"); > > > > For this failure rs6000 specific, this check does take effect, but it's too > late for this case. Since we already decide to re-try vector modes for > epilogue in vect_analyze_loop, the retrying generates one extra unexpected > statement in dumping file. Without the culprit commit, it doesn't have any > re-tries. Yeah, I think this just shows that it's a flaky test. Does it really matter that: permutation requires at least three vectors is printed exactly once, rather than at least once? It's inevitable that we'll start printing more stuff when trying (and possibly failing) to use other vectorisation strategies.
