Am 16. Juni 2018 18:38:40 MESZ schrieb Steve Kargl
<s...@troutmask.apl.washington.edu>:
>On Sat, Jun 16, 2018 at 01:09:36PM +0200, Janus Weil wrote:
>>
>>
>> Am 15. Juni 2018 20:38:17 MESZ schrieb Steve Kargl
><s...@troutmask.apl.washington.edu>:
>> >> But at least for pure functions, this optimization looks Ok.
>> >>
>> >
>> >Why is everyone fixated on PURE vs IMPURE functions?
>>
>> Simply because it makes a difference in this context!
>
>It does not! A function marked as PURE by a programmer
>must meet certain requirement of the Fortran standard.
>An unmarked function or a function marked as IMPURE can
>still meet those same requirements. Marking something as
>IMPURE has only a single requirement in the standard.
>
> An impure elemental procedure processes array arguments
> in array element order.
>
>That's it. Marking a function as IMPURE does not mean
>the function has side effects. It does not mean that
>a function must be evaluated for each reference. Are
>you advocating that gfortran must evaluate ping()
>twice for
>
> impure real function ping()
> end function ping
>
> x = ping() + 0 * ping()
> end
Absolutely, sir. That's what I'm advocating. If someone deliberately declares a
function as impure, he should be prepared to deal with the consequences. In
general, though, one can wonder whether the compiler could not warn that the
impure declaration is not necessary (or, in other words, that the function
would be better declared as pure).
In any case, the example you're showing is probably not the most problematic
one. I assume a much more frequent and critical case would be the one where
people forget to mark a function that is effectively pure with the PURE
attribute.
However, IIUC, gfortran has the ability to detect that a function meets all
pureness requirements and mark it as implicit_pure, so that it can be treated
like a pure procedure, even without any explicit PURE declaration by the
programmer.
If that's the case, the scheme I proposed should not even have any major
performance penalty, since the pureness of a function without explicit
pure/impure declaration can be automatically detected, and appropriate
optimizations can be chosen.
Therefore the most reasonable strategy I can see is still to apply
short-circuiting only to pure functions (explicit or implicit) and avoid it for
impure ones.
Cheers,
Janus
