[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law --- Fixed by recent commit on trunk.
[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 --- Comment #5 from Jeffrey A. Law --- Author: law Date: Wed Jan 22 21:27:38 2014 New Revision: 206941 URL: http://gcc.gnu.org/viewcvs?rev=206941&root=gcc&view=rev Log: PR tree-optimization/59597 * tree-ssa-threadupdate.c (dump_jump_thread_path): Move to earlier in file. Accept new argument REGISTERING and use it to modify dump output appropriately. (register_jump_thread): Corresponding changes. (mark_threaded_blocks): Reinstate code to cancel unprofitable thread paths involving joiner blocks. Add code to dump cancelled jump threading paths. PR tree-optimization/59597 * gcc.dg/tree-ssa/pr59597.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr59597.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 --- Comment #4 from Igor Zamyatin --- That would be great, thanks in advance!
[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 --- Comment #3 from Jeffrey A. Law --- This test is certainly exhibiting one of the problematical behaviours I was concerned about and had noted during the development of the FSM optimization code. Specifically, we might have a block where we can trivially thread all the incoming edges to specific outgoing edges. A great example might look like: ;; basic block 13, loop depth 2 ;;pred: 11 ;;12 # crc_205 = PHI # carry_206 = PHI <0(11), 1(12)> crc_207 = crc_205 >> 1; if (carry_206 != 0) goto ; else goto ; ;;succ: 14 ;;15 Of course, the threading code detects this and registers the appropriate jump threads. Where things go bad is BB13 may be on other jump threading paths. For example, this: Registering jump thread: (9, 11) incoming edge; (11, 13) joiner; (13, 15) normal; This will result in BB11 and BB13 being cloned. This doesn't really buy us anything. It's not clear if that's the cause of the slowdown or not, but it's clearly wasteful. Somewhere around here I've got some code to detect this kind of situation and do something more sensible. I've got to find it, update it and see if it improves things.
[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #2 from Jeffrey A. Law --- Thanks. It's a few deep in the queue, but definitely on my list.
[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 H.J. Lu changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-25 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed: r206002 gives 5.771u 0.002s 0:05.77 100.0%0+0k 0+0io 0pf+0w and gcc version 4.8.2 2.728u 0.001s 0:02.73 99.6%0+0k 0+0io 2pf+0w The change occurred between r205073 (2013-11-20, fast) and r205099 (2013-11-20, slow).