From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id E1F063858416; Thu, 28 Oct 2021 16:35:35 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E1F063858416
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/102983] [12 Regression] Dead Code Elimination
 Regression at -O3 (trunk vs 11.2.0)
Date: Thu, 28 Oct 2021 16:35:35 +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: 12.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amacleod at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-102983-4-tR6L2BBD1j@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102983-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102983-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2021 16:35:36 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102983

--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> ---
This is a bit more interesting.
The IL starts the pass as

 <bb 5> :
  if (c_3 < b_4)
    goto <bb 6>; [INV]
  else
    goto <bb 9>; [INV]

  <bb 6> :
  if (c_3 !=3D 0)
    goto <bb 7>; [INV]
  else
    goto <bb 8>; [INV]

<...>
  <bb 11> :
  # c_3 =3D PHI <0(2), c_2(10)>
  # b_4 =3D PHI <0(2), b_16(10)>
  if (b_4 <=3D 0)
    goto <bb 3>; [INV]
  else
    goto <bb 12>; [INV]

so the initial condition is "if (c_3 < b_4)"
the initial attempt to calculate c_3 =3D PHI flows along and uses a value o=
f b_4
determined by loop analysis of [0,1].  (we haven't gotten to propagating b_4
along the back edges yet)  so it ends up deciding c_3 has a range of [-INF,=
 1]
We then plod along, and eventually handle b_4, and propagate that b_4 is [0=
,0[
on the edge 11->3.

There is no direct dependency between c_3 and b_4, so there are no values g=
oing
stale due to this updated value.

Meanwhile, we eventually visit the if (c_3 < b_4) stmt, and b_4 is known to=
 be
0, so the simplifier changes this to if (c_3 < 0).=20

Ranger however, doesnt know this was simplified, and at the moment doesn't
think it needs to recalculate any outgoing ranges and update on-entry cache
values in successor blocks. It dDoesn't realize there is a reason to
recalculate it.

Whenever we successfully fold or simplify a conditional, we probably need to
check if any values should then be propagated.  I believe that it will happ=
en
automatically for anything that is defined by the statement due to the natu=
re
of the temporal cache.  Statements like GIMPLE_COND which have no LHS have =
no
triggers.=