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 DD7E7385803F; Tue, 16 Nov 2021 21:16:47 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DD7E7385803F
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/103281] [9/10/12 Regression] Dead Code
 Elimination Regression at -O3 (trunk vs 11.2.0)
Date: Tue, 16 Nov 2021 21:16:47 +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, needs-bisection
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
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: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-103281-4-PUzaCMAeHh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-103281-4@http.gcc.gnu.org/bugzilla/>
References: <bug-103281-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: Tue, 16 Nov 2021 21:16:48 -0000

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> The only thing which PHIOPT does is change:
>   if (c_15 =3D=3D 0)
>     goto <bb 4>; [INV]
>   else
>     goto <bb 5>; [INV]
>=20
>   <bb 4> :
>=20
>   <bb 5> :
>   # iftmp.1_10 =3D PHI <0(4), c_15(3)>
>=20
> to be:
> iftmp.1_10 =3D c_15;
>=20
> This is a missed VRP:
>   # RANGE [0, 2] NONZERO 3
>   c_9 =3D (charD.10) b.4_5;
>   _1 =3D c_9 <=3D 0;
>   # RANGE [0, 1] NONZERO 1
>   _2 =3D (unsigned intD.14) _1;
>   if (_2 =3D=3D b.4_5)

Note it just happens that iftmp.1_10 case of being 0 is the only that matte=
rs
to be "peeled" off and special cased.

Plus it just happens:
    char a =3D c ? c : c << 1;

Is hiding the relationship between a and c.

GCC does optimize if we change the loop to:
b >=3D 1 && b < 4

What we need to realize is that 0 needs to "peeled" off and tried seperately
with the range. that is the following two ranges need to be done seperately=
 for
b.4_5:
[0, 0] [1, 2]
But how do GCC decides that is "hard".
we know the range of _1 to be [0,1] so we need to figure out the ranges of =
c_9
which cause 0 and which one causes 1.  This is not just a forward looking
alogrothim but need to look back really. It can be very computational
instensive too.=