https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #24 from rguenther at suse dot de ---
On Mon, 8 Feb 2016, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
>
> --- Comment #23 from Jeffrey A. Law ---
> I don't think it's worth the effort to try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #23 from Jeffrey A. Law ---
I don't think it's worth the effort to try and keep that list sorted. I think
we can get what we want with a single walk over the IL just before coalescing.
That addresses the stability issue.
Then we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #22 from rguenther at suse dot de ---
On Tue, 26 Jan 2016, afomin.mailbox at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
>
> --- Comment #21 from Alexander Fomin ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #16 from Richard Biener ---
Created attachment 37474
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37474=edit
patch for SSA name management
This patch changes SSA name freelist management to keep the freelist sorted
and at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #17 from Alexander Fomin ---
Unfortunately, it doesn't. Moreover, it causes another perf loss (about 1.2%).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #18 from Richard Biener ---
(In reply to Alexander Fomin from comment #17)
> Unfortunately, it doesn't. Moreover, it causes another perf loss (about
> 1.2%).
Heh. What about testcases?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #20 from rguenther at suse dot de ---
On Tue, 26 Jan 2016, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
>
> --- Comment #19 from Jeffrey A. Law ---
> What's initially more important than a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #19 from Jeffrey A. Law ---
What's initially more important than a particular improvement or degradation of
performance is bringing more stability to the coalescing results -- so that we
can focus on issues with coalescing rather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #21 from Alexander Fomin ---
(In reply to Richard Biener from comment #18)
> Heh. What about testcases?
We don't have a reproducer yet, but I can provide any RTL dumps immediately (of
course).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
Alexander Fomin changed:
What|Removed |Added
Attachment #37037|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #14 from Jeffrey A. Law ---
Thanks. This is definitely an issue with the changing version #s changing the
ordering in which particular coalescing pairs are tried.
This is most likely coming from this (and related) code in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #12 from Jeffrey A. Law ---
Ah nuts. The partitioning information is part of the .expand dump, not the
.optimized dump. -fdump-rtl-expand-details.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #11 from Alexander Fomin ---
Created attachment 37037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37037=edit
Detailed dumps
Attached the detailed dumps for optimized SSA tree.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> I think the difference is that the older flush_ssaname_freelist loop added
> the SSA_NAMEs from FREE_SSANAMES_QUEUE (cfun) in reverse order, i.e. it
> first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #9 from Jeffrey A. Law ---
Without looking at the dumps or the code we generate, the only thing that makes
any sense would be the different SSA_NAME_VERSIONs resulting in different
coalescing.
If that is indeed the case, then that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #10 from Jeffrey A. Law ---
I've just scanned the provided dumps. This is almost certainly a difference in
the SSA_NAME_VERSIONs causing different coalescing. The tell-tale sign is
seeing identical code in the .optimized dump,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #6 from Igor Zamyatin ---
Created attachment 36961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36961=edit
Dumps
Profilers show that core_state_transition and calc_func indeed became slower
after r228668.
First difference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #5 from Richard Biener ---
Interesting the only effect could be different GC allocation pattern because
the non-splice variant may end up re-allocating the target vector multiple
times. But this alone should never change code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #4 from Alexander Fomin ---
It should, but for some reason we see a stable reproducible degradation between
r228667 and r228668...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #1 from Alexander Fomin ---
The degrading test is naturally CoreMark itself.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
--- Comment #3 from Richard Biener ---
Btw, that revision is unlikely a bisect, correct? It should have zero effects
on code generation.
26 matches
Mail list logo
