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 0F18B3858CDA; Tue, 10 Jan 2023 19:18:29 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0F18B3858CDA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1673378310;
	bh=3KRKWPowz/2BwI96FPhsxQAdNuxV/BI/iesYnXsJVsA=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=UHIP8BWy9oUEt1kaXOUH87nJvmk9ppGD/kwARBkh2sHgWZ6Tt7IrM7uftfqequ7+9
	 r85ONRGxrKFiyA3tyhEzjwQ1PlKEDwhNB8VsrCb8romgN2WEc5grJ0khSfY50NVKO8
	 v/McP7CwLU3JxDFe+WeqYcZH4wvpGcViifLbab18=
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/108360] [13 Regression] Dead Code Elimination
 Regression at -Os since r13-2048-g418b71c0d535bf
Date: Tue, 10 Jan 2023 19:18:29 +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: 13.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: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108360-4-QgVS0OQMJn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108360-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108360-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> ---
The IL is different in VRP2 between GCC12 and GCC13.  IN GCC 12 I see:

  <bb 2> [local count: 1073741824]:
  b.2_1 =3D b;
  _2 =3D b.2_1 <=3D 0;
  h.0_20 =3D (unsigned short) _2;
  _21 =3D h.0_20 + 65535;
  _22 =3D (short int) _21;
  _3 =3D _22 >=3D 0;
  _4 =3D (char) _3;
  f =3D _4;
  f.5_5 =3D (unsigned char) _3;
  _6 =3D f.5_5 << 4;
  e =3D _6;
  h_23 =3D (short int) _6;
  if (_6 =3D=3D 0)
    goto <bb 5>; [50.00%]
  else
    goto <bb 3>; [50.00%]

  <bb 3> [local count: 805306368]:
  _8 =3D b.2_1 =3D=3D h_23;

Global ranges for bb2 are:
_4 : char [0, 1]
f.5_5 : unsigned char [0, 1]
_6 : unsigned char [0, 0][16, 16]
h.0_20 : unsigned short [0, 1]
_21 : unsigned short [0, 0][+INF, +INF]
_22 : short int [-1, 0]

Looking at what ranger calculates for the edge 2->3 based on _6 having to b=
e 0:

2->3  (F) b.2_1 :       short int [-INF, 0]
2->3  (F) _2 :  _Bool [1, 1]
2->3  (F) _3 :  _Bool [1, 1]
2->3  (F) _4 :  char [1, 1]
2->3  (F) f.5_5 :       unsigned char [1, 1]
2->3  (F) _6 :  unsigned char [16, 16]
2->3  (F) h.0_20 :      unsigned short [1, 1]
2->3  (F) _21 :         unsigned short [0, 0]
2->3  (F) _22 :         short int [0, 0]
2->3  (F) h_23 :        short int [16, 16]

It can determine that h_23 is [16,16] and therefore _8 is always false.  and
when you use _8 =3D [0, 0]  the condition leading to the call can never be =
true
so it's eliminated.

The code sequence at -Os is quite different coming into VRP2 in GCC13.  It
involves a PHI node and the condition uses _21 =3D=3D -1  instead of _6 =3D=
=3D 0.=20=20
This cahnges what we can evaluate going out, and when we get to valuation of
_8, it sees:

_8 =3D b.2_1 =3D=3D iftmp.8_28;

and iftmp.8_28 is evaluated as [0, 0][16, 16][512, 512]

Because 0 hasnt been eliminated, we cant fold the condition.

We do still get this at -O2... just not at -Os.=