This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation


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 ***

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]