http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> 2012-12-10 12:26:21 UTC --- On Mon, 10 Dec 2012, jakub at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 > > Jakub Jelinek <jakub at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |jakub at gcc dot gnu.org > > --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-10 > 12:10:41 UTC --- > Is this slower compared to pre-r186530 gfortran, or just from the r186530 > through 187339? I think before that change on this testcase we've vectorized > just 25 loops, not 28 loops as now, and supposedly the loops for which the > r187340 change is a problem are only those that weren't vectorized before at > all. If the latter, then this wouldn't be a regression. > > Is there an easy way to detect if peeling could turn a simple_iv vectorized > load into non-!simple_iv? See my "this could be done differently now" comment - you should be able to re-use the original SCEV result, thus the non-simple_iv case should never pop up "late". Richard.
