[Bug tree-optimization/54497] New: Revision 190015 causes 22% degradation on 172.mgrid on PowerPC

[Bug tree-optimization/54497] New: Revision 190015 causes 22% degradation on 172.mgrid on PowerPC

[pthaugen at gcc dot gnu.org]

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

             Bug #: 54497
           Summary: Revision 190015 causes 22% degradation on 172.mgrid on
                    PowerPC
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: pthaugen@gcc.gnu.org
                CC: bergner@gcc.gnu.org, dehao@gcc.gnu.org
              Host: powerpc64-linux
            Target: powerpc64-linux
             Build: powerpc64-linux


Created attachment 28135
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28135
Reduced testcase

Starting with revision 190015 I'm seeing a major degradation on cpu2000
benchmark 172.mgrid. The core loop of the benchmark is in procedure RESID().
The main differences I see in the tree dumps, compared with the prior revision,
which result in the degradation are the following.

1) IPA-CP creates a clone of RESID to be used at certain call sites.

2) Predictive Commoning doesn't optimize the hot loop in the cloned version of
RESID.

The attatched testcase was reduced from mgrid.f and can be compiled with
gfortran -S -m64 -O3 -mcpu=power7 -mno-vsx -fno-inline.

In the original version, resid_, predictive commoning has unrolled the loop by
a factor of 2 so that memory refs can be resued (hot loop has 20 loads and 2
stfd). In the cloned version, resid_.constprop.0, no predictive commoning is
done and we end up with a single copy of the the loop with 32 loads and a
single store.

[Bug tree-optimization/54497] [4.8 Regression] Revision 190015 causes 22% degradation on 172.mgrid on PowerPC

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org
   Target Milestone|---                         |4.8.0
            Summary|Revision 190015 causes 22%  |[4.8 Regression] Revision
                   |degradation on 172.mgrid on |190015 causes 22%
                   |PowerPC                     |degradation on 172.mgrid on
                   |                            |PowerPC

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-09-06 10:01:41 UTC ---
I suppose the loop is no longer predicted to execute enough times?

[Bug tree-optimization/54497] [4.8 Regression] Revision 190015 causes 22% degradation on 172.mgrid on PowerPC

[pthaugen at gcc dot gnu.org]

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

--- Comment #2 from Pat Haugen <pthaugen at gcc dot gnu.org> 2012-09-06 21:05:05 UTC ---
(In reply to comment #1)
> I suppose the loop is no longer predicted to execute enough times?

I don't think that's the issue, I'm thinking it's somewhere in the data
dependence analysis. Looking at the dump before .pcom (i.e. .dceloop3), both
resid_ and resid_.constprop.0 list BB7, the inner loop block, as freq=10000.
The .pcom dump has many differences in the data analysis portion between the
two procedures, but the main difference is the analysis on resid_.constprop.0
ends with the following:

Predictive commoning failed: no suitable chains

[Bug tree-optimization/54497] [4.8 Regression] Revision 190015 causes 22% degradation on 172.mgrid on PowerPC

[dje at gcc dot gnu.org]

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

David Edelsohn <dje at gcc dot gnu.org> changed:

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

--- Comment #3 from David Edelsohn <dje at gcc dot gnu.org> 2012-09-12 15:29:26 UTC ---
Please make sure to add a testcase to the testsuite.

[Bug tree-optimization/54497] [4.8 Regression] Revision 190015 causes 22% degradation on 172.mgrid on PowerPC

[pthaugen at gcc dot gnu.org]

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

Pat Haugen <pthaugen at gcc dot gnu.org> changed:

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

--- Comment #4 from Pat Haugen <pthaugen at gcc dot gnu.org> 2012-09-21 21:54:47 UTC ---
Created attachment 28246
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28246
Further reduced testcase

Further reduced testcase that only has one predictive commoning candidate in
the RESID() loop.

[Bug tree-optimization/54497] [4.8 Regression] Revision 190015 causes 22% degradation on 172.mgrid on PowerPC

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-11-06 17:04:00 UTC ---
The profile should not be affected by clonning.  We do not re-run the
estimation and simply use what was there before...

[Bug tree-optimization/54497] [4.8 Regression] Revision 190015 causes 22% degradation on 172.mgrid on PowerPC

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-11-16 13:21:38 UTC ---
It is indeed problem with dependnecy analysis as discussed in PR55334. I am
marking this one as a dup because the other one has some more analysis in it.

*** This bug has been marked as a duplicate of bug 55334 ***