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?
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.
--
Janne Blomqvist
