public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-100934-4-0PSTUr6hWB@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-100934-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100934 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at gcc dot gnu.org --- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- 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 <bb 2> [local count: 119883187]: d.3_2 = d; a.1_1 = a; iftmp.0_17 = a.1_1 % 2; goto <bb 4>; [100.00%] <bb 12> [local count: 0]: <bb 3> [local count: 59073784]: # h_29 = PHI <0(7), h_21(12)> # f_26 = PHI <_30(7), f_31(12)> <bb 4> [local count: 239802342]: # iftmp.0_10 = PHI <iftmp.0_17(3), 0(2)> # h_28 = PHI <h_29(3), 0(2)> # f_31 = PHI <f_26(3), 0(2)> h_21 = h_28 + 1; _30 = f_31 + 1; if (h_21 != 2) goto <bb 12>; [0.00%] else goto <bb 7>; [100.00%] <bb 7> [local count: 239802342]: if (_30 != 2) goto <bb 3>; [50.01%] else goto <bb 8>; [49.99%] <bb 8> [local count: 119883187]: # iftmp.0_20 = PHI <iftmp.0_10(7)> c = d.3_2; b = iftmp.0_20; e = 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 = false; loop_father->any_likely_upper_bound = false; in fact we only have gimple-loop-interchange.cc: iloop.m_loop->any_upper_bound = false; gimple-loop-interchange.cc: oloop.m_loop->any_upper_bound = false; tree-cfgcleanup.c: dest->loop_father->any_upper_bound = false; tree-vectorizer.c: loop->any_upper_bound = 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?
next prev parent reply other threads:[~2021-06-07 13:13 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-06 20:49 [Bug tree-optimization/100934] New: wrong code at -O3 on x86_64-linux-gnu zhendong.su at inf dot ethz.ch 2021-06-06 21:07 ` [Bug tree-optimization/100934] [9/10/11/12 Regression] wrong code at -O3 during unrolling pinskia at gcc dot gnu.org 2021-06-07 8:38 ` [Bug tree-optimization/100934] [9/10/11/12 Regression] wrong code at -O3 during unrolling since r9-6299 jakub at gcc dot gnu.org 2021-06-07 8:42 ` jakub at gcc dot gnu.org 2021-06-07 10:28 ` rguenth at gcc dot gnu.org 2021-06-07 13:13 ` rguenth at gcc dot gnu.org [this message] 2021-06-11 9:28 ` rguenth at gcc dot gnu.org 2021-06-14 2:48 ` law at gcc dot gnu.org 2021-06-14 12:56 ` rguenth at gcc dot gnu.org 2021-06-14 12:59 ` jakub at gcc dot gnu.org 2021-06-14 13:02 ` rguenther at suse dot de 2021-06-14 14:37 ` cvs-commit at gcc dot gnu.org 2021-06-14 14:39 ` [Bug tree-optimization/100934] [9/10/11 " rguenth at gcc dot gnu.org 2021-06-16 13:12 ` cvs-commit at gcc dot gnu.org 2021-06-16 14:24 ` [Bug tree-optimization/100934] [9/10 " cvs-commit at gcc dot gnu.org 2021-10-13 10:09 ` [Bug tree-optimization/100934] [9 " cvs-commit at gcc dot gnu.org 2021-10-13 10:10 ` rguenth at gcc dot gnu.org 2021-11-09 7:57 ` pinskia at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-100934-4-0PSTUr6hWB@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).