[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340

[rguenther at suse dot de]

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.