Am 14. Juni 2018 10:05:24 MESZ schrieb Janne Blomqvist
<blomqvist.ja...@gmail.com>:
>> There is already quite some discussion in the PRs, especially 85599,
>> where not all people were of the same opinion. Let us see where the
>> discussion here leads us.
>
>IMHO it's a mistake that the standard refuses to specify the evaluation
>strategy in the name of some rather minor hypothetical performance
>benefit.
+1
I think it's pretty much the worst strategy the standard can take, and it may
even harm optimization in the end.
Optimization is always a process that involves both the programmer and the
compiler. If the programmer does not know what the compiler can and will do
with his code in the end, it's hard to write 'good' code (in the sense that it
does what was intended, and with good performance).
>Either
>
>a) short-circuiting in left-to-right order
>
>or
>
>b) must evaluate all the arguments in left-to-right order
>
>My preference would be for a) as that is what most languages are doing,
Well, C/C++ has two different kinds of operators that give you the choice to
specify whether you want short-circuiting or not.
>but
>even b) would be better than leaving it undefined.
Agreed.
In my opinion the best strategy for gfortran in the current situation would be
to apply short-circuiting whenever it can be proven that it has no observable
consequences. E.g. a function call should not be optimized away unless it is
pure.
>Also, there are AFAIU other similar weirdness with impure functions.
>The
>standard allows a compiler to optimize
>
>y = f(x) + f(x)
>
>into
>
>y = 2 * f(x)
>
>even if f is impure, which is totally bonkers. Or even not call f at
>all,
>if the compiler determines that y is not needed.
Yes, that is the same kind of craziness. I hope gfortran does not actually do
this?
Cheers,
Janus
