https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #21 from Jeffrey A. Law ---
Author: law
Date: Wed Mar 23 13:20:16 2016
New Revision: 234425
URL: https://gcc.gnu.org/viewcvs?rev=234425&root=gcc&view=rev
Log:
PR tree-optimization/64058
* tree-ssa-coalesce.c (struct c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #20 from Jeffrey A. Law ---
And FWIW, the test in this BZ is totally compromised on the trunk. Two primary
reasons. First DOM does a much better job at finding & eliminating redundant
loads. Second, erroneous path isolation finds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #19 from Jeffrey A. Law ---
Author: law
Date: Fri Mar 11 21:07:31 2016
New Revision: 234149
URL: https://gcc.gnu.org/viewcvs?rev=234149&root=gcc&view=rev
Log:
PR tree-optimization/64058
* tree-ssa-coalesce.c (struct c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
Jeffrey A. Law changed:
What|Removed |Added
CC||afomin.mailbox at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #17 from Jeffrey A. Law ---
The nice thing about looking at the conflict set sizes is it doesn't change the
computational complexity. After we've built the conflict graph we can walk the
coalesce pairs once and compute the size of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #16 from rguenther at suse dot de ---
On Thu, 10 Mar 2016, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
>
> Jeffrey A. Law changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #15 from rguenther at suse dot de ---
On Wed, 9 Mar 2016, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
>
> --- Comment #13 from Jeffrey A. Law ---
> Stabilizing the sort is just one piece in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
Jeffrey A. Law changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #13 from Jeffrey A. Law ---
Stabilizing the sort is just one piece in the problem. SSA_NAME_VERSIONs are
also used as partition numbers. That doesn't seem to impact code generation
(so far), but it does make dump comparisons bloody
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #12 from rguenther at suse dot de ---
On Tue, 8 Mar 2016, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
>
> --- Comment #11 from Jeffrey A. Law ---
> The underlying randomness of coalescing is in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #11 from Jeffrey A. Law ---
The underlying randomness of coalescing is inherently due to the instability of
SSA_NAME_VERSION. If we make SSA_NAME_VERSION stable, then the randomness of
coalescing goes away.
So I essentially toss awa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #10 from rguenther at suse dot de ---
On March 8, 2016 8:39:34 PM GMT+01:00, law at redhat dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
>
>--- Comment #9 from Jeffrey A. Law ---
>So if I take my code to renumbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #9 from Jeffrey A. Law ---
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 tw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
Richard Biener changed:
What|Removed |Added
Target Milestone|5.3 |5.4
--- Comment #8 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
Richard Biener changed:
What|Removed |Added
Target Milestone|5.2 |5.3
--- Comment #7 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|5.0 |5.2
--- Comment #6 from Jakub Jelinek -
16 matches
Mail list logo