https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Kewen Lin <li...@gcc.gnu.org>: https://gcc.gnu.org/g:f907cf4c07cf51863dadbe90894e2ae3382bada5 commit r13-1083-gf907cf4c07cf51863dadbe90894e2ae3382bada5 Author: Kewen Lin <li...@linux.ibm.com> Date: Tue Jun 14 00:57:01 2022 -0500 vect: Move suggested_unroll_factor applying [PR105940] As PR105940 shown, when rs6000 port tries to assign m_suggested_unroll_factor by 4 or so, there will be ICE on: exact_div (LOOP_VINFO_VECT_FACTOR (loop_vinfo), loop_vinfo->suggested_unroll_factor); In function vect_analyze_loop_2, the current place of suggested_unroll_factor applying can't guarantee it's applied for all cases. As the case shows, vectorizer could retry with SLP forced off, the vf is reset by saved_vectorization_factor which isn't applied with suggested_unroll_factor before. It means it can end up with one vf which neglects suggested_unroll_factor. I think it's off design, we should move the applying of suggested_unroll_factor after start_over. PR tree-optimization/105940 gcc/ChangeLog: * tree-vect-loop.cc (vect_analyze_loop_2): Move the place of applying suggested_unroll_factor after start_over.
