From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 75DF93856DC2; Wed, 20 Apr 2022 15:38:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 75DF93856DC2 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/105276] [12 Regression] executed once loop not optimized anymore Date: Wed, 20 Apr 2022 15:38:48 +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: jakub 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: keywords cc everconfirmed bug_status cf_reconfirmed_on Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2022 15:38:48 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105276 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs-bisection | CC| |amacleod at redhat dot com, | |jakub at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed| |2022-04-20 --- Comment #2 from Jakub Jelinek --- Started with r12-5688-gcb137e85720654e41db370d952df226654e576a6 The difference starts in vrp2, where the actual IL change is: - _5 =3D (bool) i_16; - _12 =3D i_16; + _5 =3D i_16 !=3D 0; + _12 =3D (unsigned int) _5; and the ranges changes are: -i_1 : unsigned int [0, 1] +i_1 : unsigned int [0, 2] i_7 : unsigned int [0, 2] -i_8 : unsigned int [0, 1][+INF, +INF] +i_8 : unsigned int [0, 2][+INF, +INF] _12 : unsigned int [0, 1] i_13 : unsigned int [1, +INF] -i_14 : unsigned int [1, 1][+INF, +INF] -i_16 : unsigned int [0, 1] +i_14 : unsigned int [1, 2][+INF, +INF] +i_16 : unsigned int [0, 2] The old ranges were narrower and I think correct. i_7 =3D i_13 % 3; ... if (i_7 !=3D 2) ... # i_16 =3D PHI _5 =3D i_16 !=3D 0; _12 =3D (unsigned int) _5; i_8 =3D i_16 - _12; if (i_8 !=3D 0) ... # i_14 =3D PHI i_1 =3D i_14 % 3; Now, that i =3D i % 3; (i=3D=3D2 ? 2 : i ? 1 : 0) in the source is just an obfuscated way of saying i =3D i % 3; i so obviously the loop will iterate at most once (0 times if i is 0, otherwi= se there will be i =3D i - i; and it will be zero at the end of the first iteration). That is something the ranger doesn't need to decipher obviously, but the above means i_7 is [0, 2], on i_16 PHI i_7 is known to be [0, 1], so assumi= ng it comes from that edge, i_8 is [0, 1][+INF, +INF] aka ~[2, 0xfffffffe], for 0 it doesn't even jump to i_14 PHI (but 0 % 3 is 0), for i_14 =3D=3D 1 = is 1 % 3 1 and for i_14 =3D=3D -1U is -1U % 3 =3D=3D 0. So, i_1 is in [0, 1] range = and loops, so the original assumptions that i_16 is [0, 1] don't change.=