[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 law at gcc dot gnu.org --- Author: law Date: Wed Jan 22 21:27:38 2014 New Revision: 206941 URL: http://gcc.gnu.org/viewcvs?rev=206941root=gccview=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 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law law at redhat dot com --- 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 #3 from Jeffrey A. Law law at redhat dot com --- 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 crc_194(11), crc_204(12) # carry_206 = PHI 0(11), 1(12) crc_207 = crc_205 1; if (carry_206 != 0) goto bb 14; else goto bb 15; ;;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 --- Comment #4 from Igor Zamyatin izamyatin at gmail dot com --- 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 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #2 from Jeffrey A. Law law at redhat dot com --- 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 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-25 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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).
[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 hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.9.0
