Am 16. Juni 2018 21:43:08 MESZ schrieb Steve Kargl
<s...@troutmask.apl.washington.edu>:
>On Sat, Jun 16, 2018 at 09:21:16PM +0200, Janus Weil wrote:
>>
>>
>> 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,i
>> that the function would be better declared as pure).
>
>This is a different answer than what you gave in
>the PR when I asked if you were special casing
>.and. and .or.
Possibly we're having a communication issue here. I don't quite understand what
you mean by "special casing".
>It is trivial to force the evaluation
>of operands. I already posted the diff in the PR
I know it's rather trivial to do this. Instead of using temporaries, as you
propose, one could also use a proper middle-end operator, like BIT_AND_EXPR
instead of TRUTH_AND_EXPR.
The non-trivial part is obviously to find a consensus about what should be done.
>> 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.
>
>See Fortran 2018, Note 10.28 (if I remember correctly).
>That example explicitly involves .and., and it explicitly
>states that a function need not be evaluate. It does
>not sya "pure function". It says "function".
You can stop throwing standard quotes. I do know what the standard says about
this by now.
Point is: It does not sound very reasonable to me and I agree with Janne that
the standard's treatment of impure functions is somewhere between careless and
insane.
If the standard says it's ok to optimize out any kind of function, I would tend
to take this less as an encouragement to compiler writers to absolutely do this
under any circumstance, but rather as saying: "Those compiler people are smart
enough. They can figure out where it makes sense all by themselves."
I happen to hold the opinion that optimizing out a call to a pure function may
be reasonable if it does not influence the result of an expression, but
optimizing out an effectively impure function (i.e. one with side effects) is
not a good idea at any time, since such an 'optimization' can drastically
change the program flow and all numerical results of a piece of code. (Note the
the standard does not require this kind of optimization either, and other
popular compilers, like ifort, do not do it.)
If we can find some kind of agreement that what I'm proposing is a reasonable
thing to do, I will certainly be happy to provide a patch (however I will not
be able to get to it before next weekend).
Right now I feel like I'm running into various walls. Janne is basically the
only one so far who expressed at least partial agreement with some of my
notions, so I certainly don't feel very encouraged to even start working on a
patch ...
Cheers,
Janus
