https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110649
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jan Hubicka <hubi...@gcc.gnu.org>: https://gcc.gnu.org/g:061f74c06735e1fa35b910ae0bcf01b61a74ec23 commit r14-2546-g061f74c06735e1fa35b910ae0bcf01b61a74ec23 Author: Jan Hubicka <j...@suse.cz> Date: Sun Jul 16 23:56:59 2023 +0200 Fix profile update in scale_profile_for_vect_loop When vectorizing 4 times, we sometimes do for <4x vectorized body> for <2x vectorized body> for <1x vectorized body> Here the second two fors handling epilogue never iterates. Currently vecotrizer thinks that the middle for itrates twice. This turns out to be scale_profile_for_vect_loop that uses niter_for_unrolled_loop. At that time we know epilogue will iterate at most 2 times but niter_for_unrolled_loop does not know that the last iteration will be taken by the epilogue-of-epilogue and thus it think that the loop may iterate once and exit in middle of second iteration. We already do correct job updating niter bounds and this is just ordering issue. This patch makes us to first update the bounds and then do updating of the loop. I re-implemented the function more correctly and precisely. The loop reducing iteration factor for overly flat profiles is bit funny, but only other method I can think of is to compute sreal scale that would have similar overhead I think. Bootstrapped/regtested x86_64-linux, will commit it shortly. gcc/ChangeLog: PR middle-end/110649 * tree-vect-loop.cc (scale_profile_for_vect_loop): Rewrite. (vect_transform_loop): Move scale_profile_for_vect_loop after upper bound updates.
