From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-446088-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 29806 invoked by alias); 12 Mar 2014 10:27:29 -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 29760 invoked by uid 48); 12 Mar 2014 10:27:25 -0000
From: "amker.cheng at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug regression/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4
Date: Wed, 12 Mar 2014 10:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: regression
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amker.cheng at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60363-4-Mv1oChToO5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60363-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60363-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-03/txt/msg00957.txt.bz2

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

--- Comment #7 from bin.cheng <amker.cheng at gmail dot com> ---
The problem has nothing to do with VRP, and might be a missed opportunity of
jump threading.

The dump after VRP but before jump threading at the end of VRP is like:

...

  <bb 21>:
  goto <bb 7>;

...

  <bb 7>:
  # kill_elt_3 = PHI <kill_elt_4(20), 0B(21), kill_elt_2(6)>
  if (b_elt_11(D) != 0B)
    goto <bb 8>;
  else
    goto <bb 14>;

  <bb 8>:
  if (kill_elt_3 != 0B)
    goto <bb 9>;
  else
    goto <bb 22>;

  <bb 22>:
  goto <bb 14>;

...

  <bb 14>:
  # changed_19 = PHI <changed_1(7), changed_1(22), changed_26(12),
changed_1(11), changed_1(9)>
  # kill_elt_18 = PHI <kill_elt_3(7), 0B(22), kill_elt_3(12), kill_elt_3(11),
kill_elt_3(9)>

  <bb 17>:
  # changed_1 = PHI <changed_19(14), 0(2)>
  # kill_elt_4 = PHI <kill_elt_18(14), kill_elt_7(D)(2)>
  if (a_elt_9(D) != 0B)
    goto <bb 24>;
  else
    goto <bb 15>;

There is jump threading path like:
  Registering jump thread: (21, 7) incoming edge;  (7, 8) joiner;  (8, 22)
normal;

After jump threading, the dump is like:
  <bb 18>:
  # kill_elt_2 = PHI <kill_elt_10(5), kill_elt_14(4)>
  if (kill_elt_2 != 0B)
    goto <bb 6>;
  else
    goto <bb 21>;

  <bb 21>:
  goto <bb 27>;

...

  <bb 14>:
  # changed_19 = PHI <changed_1(7), changed_1(22), changed_26(12),
changed_1(11), changed_1(9), changed_1(27), changed_1(29)>
  # kill_elt_18 = PHI <kill_elt_3(7), 0B(26), kill_elt_3(12), kill_elt_3(11),
kill_elt_3(9), kill_elt_3(27), kill_elt_3(29)>

  <bb 17>:
  # changed_1 = PHI <changed_19(14), 0(2)>
  # kill_elt_4 = PHI <kill_elt_18(14), kill_elt_7(D)(2)>
  if (a_elt_9(D) != 0B)
    goto <bb 24>;
  else
    goto <bb 15>;

...

  <bb 26>:
  goto <bb 14>;

  <bb 27>:
  # kill_elt_41 = PHI <0B(21)>
  if (b_elt_11(D) != 0B)
    goto <bb 26>;
  else
    goto <bb 14>;

During jump threading process, GCC updates phi node in destination basic block
like "kill_elt_18 = PHI <".  Because bb27 is duplicated from bb7, the phi
argument "kill_elt_3(27)" is copied directly from "kill_elt_3(7)".  Although
"kill_elt_3 == 0" holds when coming from edge <bb27, bb14>, gcc doesn't know
this fact.
At last, cfgcleanup tries to remove forwarder block bb26, but it can't make it
because the phi arguments from edge<bb27, bb14> and edge<bb26, bb14> doesn't
match.

I am thinking maybe jump threading can back trace the threading path and try to
add phi argument for edge<bb27, bb14> with the value(0) of kill_elt_3 (i.e.,
"0(27)").  The value is available along the jump threading path.