This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation
- From: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 10 Mar 2016 20:25:24 +0000
- Subject: [Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation
- Auto-submitted: auto-generated
- References: <bug-68654-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #25 from Jeffrey A. Law <law at redhat dot com> ---
Essentially the same problem as 64058. 64058 includes a testcase, so I'm going
to make it the canonical bug to track this issue.
If I take my prototype patch for 64058 and apply it to r228667 and r228668
things stabilize considerably. All the changes in core_list_mergesort and its
constprop variant disappear, leaving us with trivial changes in
core_bench_list.
The core_bench_list changes do not involve any additional copies -- they're
cases where we swap the operands of comparisons due to changes in the
SSA_NAME_VERSIONs and one trivial difference where a copy is sunk one
instruction.
If I compare r228667 to r228668+my patch I do see considerable changes to the
constprop variant of core_list_mergesort. That's not unexpected because
r228667 essentially randomly orders coalesce pairs with the same cost while
228668 will apply a real tie-breaking heuristic. When I look at the resulting
code it appears that we get fewer copies and with 228668+my patch when compared
to 228667 -- which is likely a good thing.
Anyway, I'm confident that addressing 64058 will also address 68654.
*** This bug has been marked as a duplicate of bug 64058 ***