public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "matz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/99101] optimization bug with -ffinite-loops Date: Wed, 03 Mar 2021 14:00:35 +0000 [thread overview] Message-ID: <bug-99101-4-IswGzWjAGs@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99101-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101 --- Comment #22 from Michael Matz <matz at gcc dot gnu.org> --- Over the last days I came to a similar conclusion. Control dependence as defined with postdoms doesn't capture the number of invocations of an instruction, just wether it's invoked at all. I.e. paths with and without cycles are regarded the same on that level. Basically the path expression for the testcase is (just inner loop): (bb11 -> bb4 -> ((bb5->bb9) | (bb6 -> (bb7->leave-cycle | bb9))))* It's clear that bb7 is reached exactly once (because as soon as it's reached it's also the end of this function, and it must be reached because it's the only end of the function). The thing with bb6 is that it can be invoked many times, and doesn't always need to lead to bb7, but rather can fall into bb9 (and the cycle restarts). But it's also the case that bb6 doesn't need to be invoked in _all_ invocations of the cycle. bb4 can choose to skip it (via bb5->bb9). So, while it's true that bb6 and bb7 are not control dependend on bb4 in the post-domincance formulation it's pretty clear that bb4 isn't useless because it exactly can cause bb6 to be skipped _in the current cycle_. If control dependence via postdoms doesn't capture the number of invocations of a node then it simply cannot be used in cyclic regions to determine uselessness of predicates.
next prev parent reply other threads:[~2021-03-03 14:00 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-15 8:55 [Bug c++/99101] New: " 251078896 at qq dot com 2021-02-15 9:43 ` [Bug tree-optimization/99101] " rguenth at gcc dot gnu.org 2021-02-15 10:17 ` rguenth at gcc dot gnu.org 2021-02-15 10:25 ` 251078896 at qq dot com 2021-02-15 10:29 ` jakub at gcc dot gnu.org 2021-02-15 10:38 ` rguenth at gcc dot gnu.org 2021-02-15 10:46 ` rguenth at gcc dot gnu.org 2021-02-15 13:08 ` rguenth at gcc dot gnu.org 2021-02-24 14:00 ` rguenth at gcc dot gnu.org 2021-02-24 14:20 ` rguenth at gcc dot gnu.org 2021-02-24 14:41 ` rguenth at gcc dot gnu.org 2021-02-24 14:45 ` rguenth at gcc dot gnu.org 2021-02-24 15:09 ` rguenth at gcc dot gnu.org 2021-02-25 10:18 ` rguenth at gcc dot gnu.org 2021-02-25 11:34 ` rguenth at gcc dot gnu.org 2021-02-25 12:09 ` rguenth at gcc dot gnu.org 2021-02-25 12:40 ` rguenth at gcc dot gnu.org 2021-02-25 13:31 ` matz at gcc dot gnu.org 2021-02-25 18:29 ` matz at gcc dot gnu.org 2021-02-25 18:34 ` matz at gcc dot gnu.org 2021-02-26 9:38 ` rguenth at gcc dot gnu.org 2021-03-03 12:16 ` rguenth at gcc dot gnu.org 2021-03-03 14:00 ` matz at gcc dot gnu.org [this message] 2021-03-03 14:37 ` rguenth at gcc dot gnu.org 2021-03-03 19:52 ` hubicka 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-99101-4-IswGzWjAGs@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).