[Bug fortran/110888] New: Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

[Bug fortran/110888] New: Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

[rimvydas.jas at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888

            Bug ID: 110888
           Summary: Missing optimization for trivial MATMUL cases,
                    requires -fno-signed-zeros
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

$ cat foo.f90
subroutine foo(x,y,z)
  implicit none
  real(kind=selected_real_kind(9,99)) :: x(1), y(1,1), z(1)
  z = matmul(x,y)
end subroutine

$ gfortran -c -S -Wall -Wextra -O2 -fdump-tree-optimized foo.f90

The do loop get reduced in matmul intrinsic implementation, however redundant
accumulator store is not optimized out during PRE if
-ffast-math(-fno-signed-zeros) is not used:
   <bb 2> [local count: 536870912]:
   __builtin_memset (z_11(D), 0, 8);
-  _18 = (*z_11(D))[0];
   _19 = (*x_13(D))[0];
   _20 = (*y_14(D))[0];
   _21 = _19 * _20;
-  _22 = _18 + _21;
+  _22 = _21 + 0.0;
   (*z_11(D))[0] = _22;
   return;

Not sure if it is possible to mark accumulator expr as artificial so that
optimizers could ignore side effects by default, but luckily it is easily
avoidable in frontend itself.

[Bug fortran/110888] Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

[rimvydas.jas at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888

--- Comment #1 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
Created attachment 55680
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55680&action=edit
possible fix

With this patch an extra register is freed and compiler produces expected code
on x86_64:
        movsd   (%rdi), %xmm0
        mulsd   (%rsi), %xmm0
        movsd   %xmm0, (%rdx)
        ret

Patch could be expanded to consider inlining trivial matmul cases even for
known arrays of size 1 with rank > 2.

[Bug fortran/110888] Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu.org,
                   |                            |tkoenig at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Copying Thomas on this and adding myself.

[Bug middle-end/110888] Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |middle-end

--- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Interesting problem.

For

  _19 = (*x_13(D))[0];
  _20 = (*y_14(D))[0];
  _21 = _19 * _20;
  _22 = _21 + 0.0;

the multiplication cannot produce a signalling NaN, so the addition
of zero should always be a no-op. For this, a simpler test case would
be

double add(double a, double b)
{
  return a*b + 0.0;
}

which gets me, on x86_64, 

        mulsd   %xmm1, %xmm0
        pxor    %xmm1, %xmm1
        addsd   %xmm1, %xmm0
        re

According to godbolt, icc produces

add:
        mulsd     %xmm1, %xmm0                                  #3.12
        ret                           

which should be fine.

So, an issue for tree optimization?

[Bug fortran/110888] Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |fortran

--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Hm, on second thoughts, signed zeros are an issue, resetting to Fortran.

Generally, we are in an intrinsic, so we can do whatever we please
(we certainly do in the library case, and this is expected behavior).

Having -ffast-math applied locally to the BLOCK that the matmul
is executed in would be a possibility.

[Bug fortran/110888] Missing optimization for trivial MATMUL cases, requires -fno-signed-zeros

[rimvydas.jas at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888

--- Comment #5 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
It is more like this problem:
$ cat foo.c
void foo_(double *x, double *y, double *z)
{
  int i;
  __builtin_memset(z, 0, 8); /* z[0] = 0.0; */
  for (i=0; i<1 ; i++)
    z[0] += x[0] * y[0];
}

$ gcc -O2 -Wall -Wextra -c foo.c -S -fdump-tree-optimized
  <bb 2> [local count: 536870913]:
  __builtin_memset (z_9(D), 0, 8);
  _17 = *x_11(D);
  _18 = *y_12(D);
  _19 = _17 * _18;
  _20 = _19 + 0.0;
  *z_9(D) = _20;
  return;

It would be beneficial for all frontends if the use of __builtin_memset() to
zero out accumulators would be be considered as !HONOR_SIGNED_ZEROS at least
during PRE pass in the middle-end.  If that would complicate things, then
easier solution is to add special case in gfortran frontend-passes that simply
transforms expression to drop accumulator: z[0] = x[0] * y[0];

* side note, in C the redundant __builtin_memset() does not get optimized out,
unlike in gfortran "zero" expr version.  Might be middle-end optimization
passes ordering issue.  At least PRE pass does take accumulator zeroing into
account.