This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/54497] New: Revision 190015 causes 22% degradation on 172.mgrid on PowerPC
- From: "pthaugen at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 05 Sep 2012 21:46:08 +0000
- Subject: [Bug tree-optimization/54497] New: Revision 190015 causes 22% degradation on 172.mgrid on PowerPC
- Auto-submitted: auto-generated
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.