public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-105276-4-ryS4njeiZY@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-105276-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105276 Jakub Jelinek <jakub at gcc dot gnu.org> 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 <jakub at gcc dot gnu.org> --- Started with r12-5688-gcb137e85720654e41db370d952df226654e576a6 The difference starts in vrp2, where the actual IL change is: - _5 = (bool) i_16; - _12 = i_16; + _5 = i_16 != 0; + _12 = (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 = i_13 % 3; ... if (i_7 != 2) ... # i_16 = PHI <i_7(3), i_1(5)> _5 = i_16 != 0; _12 = (unsigned int) _5; i_8 = i_16 - _12; if (i_8 != 0) ... # i_14 = PHI <i_8(4)> i_1 = i_14 % 3; Now, that i = i % 3; (i==2 ? 2 : i ? 1 : 0) in the source is just an obfuscated way of saying i = i % 3; i so obviously the loop will iterate at most once (0 times if i is 0, otherwise there will be i = 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 assuming 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 == 1 is 1 % 3 1 and for i_14 == -1U is -1U % 3 == 0. So, i_1 is in [0, 1] range and loops, so the original assumptions that i_16 is [0, 1] don't change.
next prev parent reply other threads:[~2022-04-20 15:38 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-14 13:47 [Bug c/105276] New: " denis.campredon at gmail dot com 2022-04-19 8:29 ` [Bug tree-optimization/105276] " rguenth at gcc dot gnu.org 2022-04-20 15:38 ` jakub at gcc dot gnu.org [this message] 2022-04-21 15:46 ` amacleod at redhat dot com 2022-04-25 13:59 ` cvs-commit at gcc dot gnu.org 2022-04-25 14:27 ` amacleod at redhat dot com
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-105276-4-ryS4njeiZY@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).