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/64058] [5/6 Regression] Performance degradation after r216304


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?

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