[Bug tree-optimization/59597] New: Performance degradation on Coremark after r205074

[Bug tree-optimization/59597] New: Performance degradation on Coremark after r205074

[izamyatin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597

            Bug ID: 59597
           Summary: Performance degradation on Coremark after r205074
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: izamyatin at gmail dot com
            Target: x86

Created attachment 31510
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31510&action=edit
reduced test

Degradation could be seen at -Ofast for the attached test which similar to the
Coremark codes

It seems that jump threading here performs unnecessary nodes duplication and as
a result if-conversion doesn't happen.

[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074

[dominiq at lps dot ens.fr]

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

[hjl.tools at gmail dot com]

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

[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074

[law at redhat dot com]

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

[law at redhat dot com]

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

[izamyatin at gmail dot com]

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

[law at gcc dot gnu.org]

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=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

[law at redhat dot com]

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.