This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/64058] [5/6 Regression] Performance degradation after r216304
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 08 Mar 2016 20:50:10 +0000
- Subject: [Bug tree-optimization/64058] [5/6 Regression] Performance degradation after r216304
- Auto-submitted: auto-generated
- References: <bug-64058-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On March 8, 2016 8:39:34 PM GMT+01:00, law at redhat dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
>
>--- Comment #9 from Jeffrey A. Law <law at redhat dot com> ---
>So if I take my code to renumber SSA_NAMES so they they're consistent
>irrespective how SSA_NAMEs were recycled and apply that on top of
>r216304 and
>r216305 the net result is I get the same code from those two compilers.
>
>That argues that ultimately this is another case of SSA_NAME_VERSION
>differences causing coalescing to make different decisions in a
>semi-random way
>which leads to random performance changes.
>
>That means this BZ and 68654 are likely manifestations of the same
>underlying
>issue.
>
>I'm still having some problems with getting consistent results across a
>larger
>codebase comparing before/after the SSA_NAME freelist flushing change,
>so
>clearly something isn't getting renumbered properly. But it's
>promising.
How is renumbering promising if it doesn't address the underlying randomness in
the coalescing decision?