https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #24 from Jan Hubicka ---
Author: hubicka
Date: Thu Feb 2 20:22:13 2017
New Revision: 245135
URL: https://gcc.gnu.org/viewcvs?rev=245135&root=gcc&view=rev
Log:
PR middle-end/77445
* gcc.dg/tree-ssa/pr77445-2.c: Updat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #23 from Jan Hubicka ---
I will implement the "allow size growth when there is a hot bb on a path"
heuristics. We may try to get smarter on when the peeling actually helps the
unpeeled path, but that is bit hard to do because there m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #22 from Jeffrey A. Law ---
In response to c#19. Yes, a thread path which is cold except for a hot block
in the middle might be profitable to thread as it will sometimes expose path
specific redundancies/simplifications in the hot bl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #21 from Jeffrey A. Law ---
In response to c#20. We have to be careful about fixing up the loop after
rotation and avoid repeatedly peeling. The old threader dealt with those by
being fairly conservative in passes before the loop op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #20 from rguenther at suse dot de ---
On Mon, 23 Jan 2017, hubicka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
>
> --- Comment #19 from Jan Hubicka ---
> One change that would make sense to me is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #19 from Jan Hubicka ---
One change that would make sense to me is to always thread when there is a
non-cold block on the path: we are not only improving the path taken when
threading but because we eliminate incoming edges we also pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #18 from Jeffrey A. Law ---
>From just looking at the paths, I would expect it to matter -- they're still
cases where we're threading the multiway branch and that's the key to this
benchmark -- avoiding the multiway branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #17 from Jan Hubicka ---
As reported in PR77484, coremark is now up by 20% or more.
Are we out of regression land now? If not does the patch in #15 help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #15 from Jan Hubicka ---
Note that the remaining missed threads loop exit condition test state !=
INVALID which after sequence of threads gets to probability 0 because original
guess from profile_estimate is not realistic.
I guess su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #14 from Jan Hubicka ---
With the patch we only give up on some threading in thread4:
q.c.181t.thread4:FSM jump-thread path not considered: duplication of 5 insns is
needed and optimizing for size.
q.c.181t.thread4:FSM jump-thread pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #13 from Jan Hubicka ---
Author: hubicka
Date: Tue Jan 17 12:49:41 2017
New Revision: 244528
URL: https://gcc.gnu.org/viewcvs?rev=244528&root=gcc&view=rev
Log:
PR middle-end/77445
* tree-ssa-threadupdate.c (remove_ct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #12 from Jan Hubicka ---
Created attachment 40526
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40526&action=edit
Patch I am testing
The profile is quite inconsistent since thread1.
The problem is that duplicate_thread_path do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #10 from rguenther at suse dot de ---
On Wed, 14 Dec 2016, jgreenhalgh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
>
> --- Comment #8 from James Greenhalgh ---
> Is anyone currently looking at thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #9 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #8 from James Greenhalgh ---
Is anyone currently looking at this?
If the bug is still blocked on correcting the profile information (which sounds
like a large job), should we consider weakening or reverting the cost model for
GCC 7?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #7 from James Greenhalgh ---
Right, I've trimmed too much context from my message.
This performance regression starts with r239219 which adds a cost model to the
threader which relies on frequency information (arguably this is a bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
James Greenhalgh changed:
What|Removed |Added
Last reconfirmed|2016-09-03 00:00:00 |2016-11-30
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #4 from Yuri Rumyantsev ---
Ping.
Do you have any progress on this?
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #1 from Yuri Rumyantsev ---
Created attachment 39535
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39535&action=edit
test-case to reproduce
It is sufficient to compile it with -Ofast option.
26 matches
Mail list logo
