Re: [patch, fortran] Handling of .and. and .or. expressions

[Janne Blomqvist <blomqvist dot janne at gmail dot com>]

On Wed, Jun 27, 2018 at 7:46 PM, Steve Kargl <
sgk@troutmask.apl.washington.edu> wrote:

> On Wed, Jun 27, 2018 at 11:09:56AM +0300, Janne Blomqvist wrote:
> >
> > 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.
> >
>
> Benchmarks aren't going to prove anything unless the
> benchmarks have the specific construct under discuss.
>

What I'm saying is that as the Fortran standard doesn't specify exactly how
logical expressions are to be evaluated, we are free to use either
short-circuiting or non-short-circuiting (or choosing between them based on
the phase of the moon). While I'm sure we may produce synthetic benchmarks
to show either to be better [1], what matters is actual applications. Hence
we should check benchmarks based on actual applications, like polyhedron or
spec. Now, if this hypothetical patch has no impact on those benchmarks,
then, well, I don't have any particular opinion whether it should be kept.

[1] While obviously short-circuiting can avoid the evaluation of an
expensive function like in your example, a naive translation of
short-circuiting would produce more branches which aren't good either
(though I guess and hope the middle end can get rid of most of them). Thus
IMHO the decision should be based on the performance impact on real
applications.


-- 
Janne Blomqvist