On Thu, Dec 11, 2014 at 11:05:13AM +0100, Richard Biener wrote:
>
> The following patch fixes the performance regression in PR42108
> by allowing PRE and LIM to see the division (to - from) / step
> in translating do loops executed unconditionally. This makes
> them not care for the fact that step might be zero and thus
> the division might trap.
>
step cannot be zero in standard conforming code. From F95 8.1.4.4,
"Execution of a DO construct":
When the DO statement is executed, the DO construct becomes active.
If loop-control is
[ , ] do-variable = scalar-int-expr1, scalar-int-expr2 [, scalar-int-expr3]
the following steps are performed in sequence:
(1) The initial parameter m1, the terminal parameter m2, and the
incrementation parameter m3 are of type integer with the same kind
type parameter as the do-variable. Their values are established by
evaluating scalar-int-expr1, scalar-int-expr2, and scalar-int-expr3,
respectively, including, if necessary, conversion to the kind type
parameter of the do-variable according to the rules for numeric
conversion (Table 7.10). If scalar-int-expr3 does not appear, m3
has the value 1. The value m3 shall not be zero.
"The value m3 shall not be zero" is a not an enumerated constraint,
so the compiler does not need to catch and report m3 being zero.
The prohibition is on the programmerr. So, if the division traps,
it is a bug in the program.
> This makes the runtime of the testcase improve from 10.7s to
> 8s (same as gfortran 4.3).
>
> The caveat is that iff the loop is not executed (to < from
> for positive step for example) then there will be an additional
> executed division computing the unused countm1.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu, ok
> for trunk?
>
OK.
--
Steve
