From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-440513-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 32488 invoked by alias); 16 Jan 2014 06:42:07 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 32455 invoked by uid 48); 16 Jan 2014 06:42:02 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
Date: Thu, 16 Jan 2014 06:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: law at redhat dot com
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59597-4-ETpPF1K3ER@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59597-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59597-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg01655.txt.bz2

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.