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

Jakub Jelinek jakub@redhat.com
Wed Jun 27 08:02:00 GMT 2018


On Wed, Jun 27, 2018 at 09:52:04AM +0200, Janus Weil wrote:
> 2018-06-27 9:42 GMT+02:00 Jakub Jelinek <jakub@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?

No, fortran/trans-decl.c has:
  /* Set attributes for PURE functions. A call to PURE function in the
     Fortran 95 sense is both pure and without side effects in the C
     sense.  */
  if (sym->attr.pure || sym->attr.implicit_pure)
    {
      if (sym->attr.function && !gfc_return_by_reference (sym))
        DECL_PURE_P (fndecl) = 1;
and calls.c has:
      if (DECL_PURE_P (exp))
        flags |= ECF_PURE;

> Ah, great. Even with TRUTH_AND_EXPR, you mean?

If one operand of TRUTH_AND_EXPR is optimized into false, then yes,
it will fold into false and thus the function result will be dead and the
call will be removed.

Though, if you mean an optimization that checks if one operand can be
computed cheaply and the other one is expensive with function calls and
optimize expensive & cheap into cheap && expensive, then no, we don't have
such an optimization (perhaps it would be worth it, but would probably need
to be done early (in the FEs or during gimplification at latest)).

	Jakub



More information about the Gcc-patches mailing list