[Bug fortran/55806] New: Missed optimization with ANY or ALL

[Bug fortran/55806] New: Missed optimization with ANY or ALL

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806

             Bug #: 55806
           Summary: Missed optimization with ANY or ALL
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: tkoenig@gcc.gnu.org


Mike Metcalf complains (correctly) in
<44daf54c-3de5-4b1c-a1f7-cb7bf0d496b0@googlegroups.com>
that using ANY as an idiom instead of .or. for a small number of conditions.



Look at this:

module mymod
contains
  subroutine bar(a,b,c)
    integer, dimension(3,3), intent(in) :: a,b
    integer, intent(out) :: c
    real, parameter :: acc = 1e-4
    integer :: i

    c = 0
    do i=1,3
       if (any([abs(a(i,1) - b(i,1)) > acc,  &
            abs(a(i,2) - b(i,2)) > acc, &
            abs(a(i,3) - b(i,3)) > acc])) cycle
       c = c + 1
    end do
  end subroutine bar
end module mymod

This generates a logical array, assigns the values to them,
and then loops over the array to generate the values:


              atmp.1.dtype = 273;
              atmp.1.dim[0].stride = 1;
              atmp.1.dim[0].lbound = 0;
              atmp.1.dim[0].ubound = 2;
              atmp.1.data = (void * restrict) &A.2;
              atmp.1.offset = 0;
              (*(logical(kind=4)[3] * restrict) atmp.1.data)[0] =
(real(kind=4)) ABS_EXPR <(*a)[(integer(kind=8)) i + -1] -
(*b)[(integer(kind=8)) i + -1]> > 9.99999974737875163555145263671875e-5;
              (*(logical(kind=4)[3] * restrict) atmp.1.data)[1] =
(real(kind=4)) ABS_EXPR <(*a)[(integer(kind=8)) i + 2] - (*b)[(integer(kind=8))
i + 2]> > 9.99999974737875163555145263671875e-5;
              (*(logical(kind=4)[3] * restrict) atmp.1.data)[2] =
(real(kind=4)) ABS_EXPR <(*a)[(integer(kind=8)) i + 5] - (*b)[(integer(kind=8))
i + 5]> > 9.99999974737875163555145263671875e-5;
              {
                integer(kind=8) S.4;

                S.4 = 0;
                while (1)
                  {
                    if (S.4 > 2) goto L.5;
                    if (NON_LVALUE_EXPR <(*(logical(kind=4)[3] * restrict)
atmp.1.data)[S.4]>)
                      {
                        test.0 = 1;
                        goto L.4;
                      }
                    S.4 = S.4 + 1;
                  }
                L.5:;
              }
              L.4:;
              if (test.0) goto L.1;
            }
            L.3:;
            *c = *c + 1;
            L.1:;
            D.1907 = i == 3;
            i = i + 1;
            if (D.1907) goto L.2;
          }

The middle-end then fails to remove this array.

Compare this to the result of

module mymod
contains
  subroutine bar(a,b,c)
    real, dimension(3,3), intent(in) :: a,b
    integer, intent(out) :: c
    real, parameter :: acc = 1e-4
    integer :: i

    c = 0.
    do i=1,3
       if (abs(a(i,1) - b(i,1)) > acc .or. &
            abs(a(i,2) - b(i,2)) > acc .or. &
            abs(a(i,3) - b(i,3)) > acc) cycle
       c = c + 1
    end do
  end subroutine bar
end module mymod

What the Fortran FE generates here isn't very idiomatic when you
write in a language like C.  Should we tackle this in the middle
end, or would issuing the version with .or instead of the ANY
to the middle end be preferred?

[Bug fortran/55806] Missed optimization with ANY or ALL

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-12-25 18:37:57 UTC ---
See https://groups.google.com/d/msg/comp.lang.fortran/Gad1-auDYuU/_F-Jt8fZIVAJ
in thread "Nearest Neighbour Search".

[Bug fortran/55806] Missed optimization with ANY or ALL

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806

--- Comment #2 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-01-14 21:50:35 UTC ---
Author: tkoenig
Date: Mon Jan 14 21:50:28 2013
New Revision: 195179

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195179
Log:
2013-01-14  Thomas Koenig  <tkoenig@gcc.gnu.org>

    PR fortran/55806
    * frontend-passes.c (optimize_reduction):  New function,
    including prototype.
    (callback_reduction):  Likewise.
    (gfc_run_passes):  Also run optimize_reduction.
    (copy_walk_reduction_arg):  New function.
    (dummy_code_callback):  New function.

2013-01-14  Thomas Koenig  <tkoenig@gcc.gnu.org>

    PR fortran/55806
    * gfortran.dg/array_constructor_40.f90:  New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/array_constructor_40.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/frontend-passes.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/55806] Missed optimization with ANY or ALL

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806

--- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-01-14 22:29:37 UTC ---
Now for something harder (which is Michael Metcalf's original idiom):

   if (any([a(1),a(2)]>acc) then...

This can be done by converting

[a1, a2, ...] binop scalar to [a1 binop scalar, a2 binop scalar, ...]

in general, followed by what has been committed already.

[Bug fortran/55806] Missed optimization with ANY or ALL

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2013-01-19
         AssignedTo|unassigned at gcc dot       |tkoenig at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-01-19 21:32:37 UTC ---
Created attachment 29223
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29223
Patch for demonstrating the concept

Here's a patch which partially does the job.  It
converts [foo, bar] binop baz into [foo binop baz, bar binop baz]
(but only going this way).

[Bug fortran/55806] Missed optimization with ANY or ALL

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #29223|0                           |1
        is obsolete|                            |

--- Comment #5 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-01-20 14:55:50 UTC ---
Created attachment 29225
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29225
Better patch

This one is not yet symmetrical, but it does not cause regressions.

[Bug fortran/55806] Missed optimization with ANY or ALL

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #29225|0                           |1
        is obsolete|                            |

--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-01-31 19:48:25 UTC ---
Created attachment 29321
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29321
Patch that works

This time, both for any([a,b,c] > eps) and any(eps < [a,b,c]).

[Bug fortran/55806] Missed optimization with ANY or ALL

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806

--- Comment #7 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-01-31 21:01:58 UTC ---
*** Bug 33341 has been marked as a duplicate of this bug. ***

[Bug fortran/55806] Missed optimization with ANY or ALL

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #8 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2013-03-28 23:25:29 UTC ---
Fixed with http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00845.html,
closing.