https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68398
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68398
--- Comment #7 from Jeffrey A. Law ---
Author: law
Date: Wed Jan 27 19:19:47 2016
New Revision: 232897
URL: https://gcc.gnu.org/viewcvs?rev=232897&root=gcc&view=rev
Log:
PR tree-optimization/68398
* params.def (PARAM_FSM_SCALE_PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68398
--- Comment #6 from Jeffrey A. Law ---
Author: law
Date: Mon Jan 25 19:19:09 2016
New Revision: 232802
URL: https://gcc.gnu.org/viewcvs?rev=232802&root=gcc&view=rev
Log:
PR tree-optimization/69196
PR tree-optimization/68398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68398
--- Comment #5 from Jeffrey A. Law ---
Doing it after the loop optimizer doesn't help. I haven't really looked into
why.
The concerns around not creating new subloops or multiple latches pre-date a
lot of the loop infrastructure changes Richi h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68398
--- Comment #4 from Sebastian Pop ---
Thanks Jeff for looking into this issue.
I was thinking about a heuristic as you mentioned in comment #2:
what about allowing creation of irreducible loops, multiple latches, etc. after
the loop optimizers ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68398
--- Comment #3 from Jeffrey A. Law ---
Actually, it's not trying to prevent an irreducible loop, it's trying prevent
creating a loop with several latches or subloops. So it's not as bad as I
first thought.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68398
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #2 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68398
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68398
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.0
Summary|coremark regressi