From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1D83F385781C; Mon, 7 Jun 2021 13:13:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1D83F385781C From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/100934] [9/10/11/12 Regression] wrong code at -O3 during unrolling since r9-6299 Date: Mon, 07 Jun 2021 13:13:30 +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: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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: Mon, 07 Jun 2021 13:13:31 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100934 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at gcc dot gnu.org --- Comment #5 from Richard Biener --- Somehow niter analysis computes two iterations for the loop but that doesn't look correct. That might be the result of extra simplification triggered by the change but it most definitely looks like a latent issue to me [local count: 119883187]: d.3_2 =3D d; a.1_1 =3D a; iftmp.0_17 =3D a.1_1 % 2; goto ; [100.00%] [local count: 0]: [local count: 59073784]: # h_29 =3D PHI <0(7), h_21(12)> # f_26 =3D PHI <_30(7), f_31(12)> [local count: 239802342]: # iftmp.0_10 =3D PHI # h_28 =3D PHI # f_31 =3D PHI h_21 =3D h_28 + 1; _30 =3D f_31 + 1; if (h_21 !=3D 2) goto ; [0.00%] else goto ; [100.00%] [local count: 239802342]: if (_30 !=3D 2) goto ; [50.01%] else goto ; [49.99%] [local count: 119883187]: # iftmp.0_20 =3D PHI c =3D d.3_2; b =3D iftmp.0_20; e =3D iftmp.0_20; return 0; } niter is chrec_don't_know but we have a set nb_iterations_upper_bound which likely survives incorrectly from some CFG merging. In fact loops are removed at a-t.c.109t.thread1:fix_loop_structure: removing loop 3 a-t.c.123t.thread2:fix_loop_structure: removing loop 2 a-t.c.152t.cddce2:fix_loop_structure: removing loop 4 loop 1 gets its nb_iterations_upper_bound in EVRP but when loop 2 is removed it is not reset appropriately. In fact thread2 creates quite some mess which includes turning loop2 into some irreducible region. There's some scattered resetting of the upper bound (estimates) but no API for this (and free_numbers_of_iterations_estimates doesn't do it). loop_father->any_upper_bound =3D false; loop_father->any_likely_upper_bound =3D false; in fact we only have gimple-loop-interchange.cc: iloop.m_loop->any_upper_bound =3D false; gimple-loop-interchange.cc: oloop.m_loop->any_upper_bound =3D false; tree-cfgcleanup.c: dest->loop_father->any_upper_bound =3D false; tree-vectorizer.c: loop->any_upper_bound =3D false; I think the backwards threader has to get some guards - whenever we thread through a loop latch edge we have to reset niter estimates/bounds. But I'm not at all familiar with said code. Jeff - do you know a single place to tackle this?=