[Bug tree-optimization/58453] New: Revision 202431 results in miscompare for CPU2006 434.zeusmp

[Bug tree-optimization/58453] New: Revision 202431 results in miscompare for CPU2006 434.zeusmp

[pthaugen at gcc dot gnu.org]

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

            Bug ID: 58453
           Summary: Revision 202431 results in miscompare for CPU2006
                    434.zeusmp
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pthaugen at gcc dot gnu.org
                CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org,
                    rguenth at gcc dot gnu.org
              Host: powerpc64-linux
            Target: powerpc64-linux
             Build: powerpc64-linux

Miscompare of 434.zeusmp started on PowerPC with revision 202431. Richi
suggested on irc to update to r202521 which contains fix for pr58396, but I'm
still seeing the miscompare. Have not been able to track down to failing
assembler yet but will attatch some files in hope that it may help.

[Bug tree-optimization/58453] Revision 202431 results in miscompare for CPU2006 434.zeusmp

[pthaugen at gcc dot gnu.org]

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

--- Comment #1 from Pat Haugen <pthaugen at gcc dot gnu.org> ---
Created attachment 30841
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30841&action=edit
Source file

pdv.f source file from benchmark, which results in successful execution if
compiled with prior revision (r202429).

Should have noted in prior comment, compile options used when building the
benchmark are:

-m64 -O3 -mcpu=power7 -fno-tree-loop-distribution -fno-tree-vectorize

(Note that failure still exists for just "-m64 -O3 -mcpu=power7" other 2
options were just included while trying to narrow down dumps/assembler for
debugging.)


Compiling with -fno-tree-loop-distribute-patterns results in benchmark success.

[Bug tree-optimization/58453] Revision 202431 results in miscompare for CPU2006 434.zeusmp

[pthaugen at gcc dot gnu.org]

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

--- Comment #2 from Pat Haugen <pthaugen at gcc dot gnu.org> ---
Created attachment 30842
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30842&action=edit
r202429 ldist dump

Loop distribution dump for pdv.f using rev 202429.

[Bug tree-optimization/58453] Revision 202431 results in miscompare for CPU2006 434.zeusmp

[pthaugen at gcc dot gnu.org]

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

--- Comment #3 from Pat Haugen <pthaugen at gcc dot gnu.org> ---
Created attachment 30843
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30843&action=edit
r202431 ldist dump

Loop distribution dump for pdv.f using rev 202431.

[Bug tree-optimization/58453] Revision 202431 results in miscompare for CPU2006 434.zeusmp

[pthaugen at gcc dot gnu.org]

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

--- Comment #4 from Pat Haugen <pthaugen at gcc dot gnu.org> ---
Just discovered that -fwrapv results in successful execution also, so possibly
bad source.

[Bug tree-optimization/58453] Revision 202431 results in miscompare for CPU2006 434.zeusmp

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ysrumyan at gmail dot com

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 58444 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2013-09-18
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
   Target Milestone|---                         |4.9.0
            Summary|Revision 202431 results in  |[4.9 Regression] Revision
                   |miscompare for CPU2006      |202431 results in
                   |434.zeusmp                  |miscompare for CPU2006
                   |                            |434.zeusmp
     Ever confirmed|0                           |1

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine.

[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
loop distribution distributes this into

             q2         = ( g2a(i+1) * g31a(i+1) * v1(i+1,j,k)
     1                    - g2a(i  ) * g31a(i  ) * v1(i  ,j,k) )
     2                  *                         dvl1ai(i)
     3                  + ( g32a(j+1) * v2(i,j+1,k)
     4                    - g32a(j  ) * v2(i,j  ,k) )
     5                  *   g2bi(i)             * dvl2ai(j)
     6                  + ( v3(i,j,k+1) - v3(i,j,k) )
     7                  *   g31bi(i) * g32bi(j) * dvl3ai(k)
             q2         = q2 * q1
             e(i,j,k)   = ( 1.0 - q2 ) / ( 1.0 + q2 ) * e(i,j,k)

and a memcpy for

             dlo(i,j,k) = d(i,j,k)

and

             eod(i,j,k) = e(i,j,k) / d(i,j,k)

(re-computing e(i,j,k) instead of loading it from the stored value - a known
deficiency)

This doesn't look wrong on the first glance (but it's probably slower).

What the revision in question changed was remove some very odd code
from rdg_flag_uses:

-  if (gimple_code (stmt) != GIMPLE_PHI)
-    {
-      if ((use_p = gimple_vuse_op (stmt)) != NULL_USE_OPERAND_P)
-       {
-         tree use = USE_FROM_PTR (use_p);
-
-         if (TREE_CODE (use) == SSA_NAME
-             && !SSA_NAME_IS_DEFAULT_DEF (use))
-           {
-             gimple def_stmt = SSA_NAME_DEF_STMT (use);
-             int v = rdg_vertex_for_stmt (rdg, def_stmt);
-
-             if (v >= 0
-                 && !already_processed_vertex_p (processed, v))
-               rdg_flag_vertex_and_dependent (rdg, v, partition, loops,
-                                              processed);
-           }
-       }
-    }

that just doesn't make sense, but it likely made sure everything ended up
in a single partition.

Does the benchmark fail if you build with -ftree-loop-distribution
-fno-tree-loop-distribute-patterns?  (it should emit a loop instead of the
memcpy call)

[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #7)
> Does the benchmark fail if you build with -ftree-loop-distribution
> -fno-tree-loop-distribute-patterns?  (it should emit a loop instead of the
> memcpy call)

of course not - we fuse the partitions because of the similar memory accesses
again.

[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, so we have

  _103 = fieldr.e[_51];
  _104 = _102 * _103;
  fieldr.e[_51] = _104;
  _106 = fieldr.d[_51];
  *dlo_107(D)[_51] = _106;
  _109 = _104 / _106;
  *eod_110(D)[_51] = _109;

and distribute it as

  _103 = fieldr.e[_51];
  _104 = _102 * _103;
  fieldr.e[_51] = _104;

  memcpy (dlo, &fieldr.d, ...)

  _103 = fieldr.e[_51];
  _104 = _102 * _103;
  _106 = fieldr.d[_51];
  _109 = _104 / _106;
  *eod_110(D)[_51] = _109;

but that's obviously wrong as we are re-loading a different fieldr.e.

Testcase:

extern void abort (void);

int a[128], b[128], c[128], d[128];

void __attribute__((noinline,noclone))
foo (void)
{
  int i;
  for (i = 0; i < 128; ++i)
    {
      a[i] = a[i] + 1;
      b[i] = d[i];
      c[i] = a[i] / d[i];
    }
}
int main()
{
  int i;
  for (i = 0; i < 128; ++i)
    a[i] = i;
  for (i = 0; i < 128; ++i)
    d[i] = 1;
  foo ();
  if (c[0] != 1)
    abort ();
  return 0;
}

[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
With -ftree-loop-distribution we fuse the first and the last partition
resulting in correct code again.  We're really missing partition dependencies -
see PR53616.

[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Fri Sep 20 12:21:08 2013
New Revision: 202775

URL: http://gcc.gnu.org/viewcvs?rev=202775&root=gcc&view=rev
Log:
2013-09-20  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/58453
    * tree-loop-distribution.c (distribute_loop): Apply the cost
    model for -ftree-loop-distribute-patterns, too.

    * gcc.dg/tree-ssa/ldist-23.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-23.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-loop-distribution.c

[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.