2018-06-27 10:09 GMT+02:00 Janne Blomqvist <blomqvist.ja...@gmail.com>: > On Wed, Jun 27, 2018 at 10:52 AM, Janus Weil <ja...@gcc.gnu.org> wrote: >> >> 2018-06-27 9:42 GMT+02:00 Jakub Jelinek <ja...@redhat.com>: >> > On Wed, Jun 27, 2018 at 09:35:59AM +0200, Janus Weil wrote: >> >> > and have some non-default aggressive >> >> > optimization option that would optimize away in the FE impure >> >> > function calls >> >> >> >> IMHO an optimization to remove functions calls is unproblematic only >> >> for pure functions, but as long as it is guarded by a non-default >> > >> > For pure functions, which are hopefully marked as ECF_PURE for the >> > middle-end >> >> Not sure if that's the case. Grepping for ECF_PURE in >> trunk/gcc/fortran only yields a single occurrence: >> >> f95-lang.c:#define ATTR_PURE_NOTHROW_LEAF_LIST (ECF_NOTHROW | >> ECF_LEAF | ECF_PURE) >> >> Seems like that is only used for built-ins? >> >> >> > the middle-end can already optimize away those calls where the >> > result isn't needed. >> >> Ah, great. Even with TRUTH_AND_EXPR, you mean? > > How about committing a patch changing to use TRUTH_{AND|OR}_EXPR, and then > check benchmark results (polyhedron, spec etc.)? If performance worsens, we > revert, if it improves, great, lets keep it?
I would definitely support that. I cannot imagine that it will have a large impact on benchmarks, but it's certainly a good idea to check. (After all: ifort, which is usually perceived as being slightly ahead of GCC in terms of performance, does not do this kind of short-circuiting either.) If the middle-end already does all 'non-problematic' optimizations by itself, all the better. > To clarify, I'm not objecting to using TRUTH_{AND|OR}_EXPR, I'm objecting to > the notion that this is somehow "more correct" or "less bad" than the > current short-circuiting. The Fortran standard does not specify an > evaluation strategy; IMHO very unfortunately, but it is what it is. It is very unfortunate, and it means that the Fortran standard simply does not provide a measure for "more correct" here. (My common-sense drop-in notion of correctness would be that an optimization is 'correct' as long as it can be proven to not change any results.) Cheers, Janus