[Bug tree-optimization/42108] [4.8/4.9/5 Regression] 50% performance regression

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108

--- Comment #65 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 10 Dec 2014, burnus at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
> 
> --- Comment #64 from Tobias Burnus <burnus at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #63)
> > Unfortunately for the testcase this doesn't allow moving the division at all
> > and we are lucky that we have range information at all because of the fortran
> > frontend casting 'n' to unsigned before dividing by it.
> 
> If it helps and the semantic is preserved, there is no reason not to 
> completely change what tree code the Fortran FE generates for loops.

The attached patch helps, but only sofar as enabling moving the division
out one loop level - if you add another nest the entry condition on it
will prevent moving the division further.

> [I think one reason for the odd way tree code for loops is generated is: The
> current code makes it simple to permit loops which are always run once, as some
> Fortran 66 compilers did. For instance, "DO i = 2, 1" would then be executed
> once. (Such loops are not permitted in F66 - and some compilers executed them
> once others zero times; since F77, such loops are permitted and executed zero
> times. Unsurprisingly, some old code from the 60s relies on the execute once
> feature.)
> 
> g77 and some commercial compilers have a compile flag like "-f66", gfortran
> hasn't and I don't think it ever will.]

I wondered if

  DO i = 1, 1, 0

is valid (a step of zero).  Note that DO i = 2, 1 wouldn't be executed
once with the current generated code, only DO i = 1, 1 is, but with
step == 0 it would divide by zero.