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: Thu, 25 Feb 2021 18:29:12 +0000	[thread overview]
Message-ID: <bug-99101-4-Dge4H4CbwL@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 #18 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #11)
> (In reply to Richard Biener from comment #10)
> > Created attachment 50248 [details]
> > dot of the CFG as CD-DCE sees it
> 
> (gdb) p debug_dominance_info (CDI_POST_DOMINATORS)
> 2 3
> 3 11
> 4 6
> 5 9
> 6 7
> 7 1
> 9 11
> 11 4
> 12 3

So, on IRC you said that the at_eof is completely eliminated.  I wonder why.
It's true that bb6 post-dominates bb4, hence bb6 is not control dependend on
bb4.

But there are other blocks control dependend on bb4, namely bb5 and bb9.
To see this observe that bb9 doesn't pdom bb4, but there's a path from bb4 to
bb9 (e.g. bb4 -> bb5 -> bb9), where one node in that path that isn't bb4 is
pdom by bb9 (here bb5 and bb9 are such path nodes).  With same reasoning also
bb5 is
control dependend on bb4 (the example path being bb4->bb5, and bb5 the only
test 
node to check for pdom by bb5).

So, we have that bb5 and bb9 are control dependend on bb4, so removing of
bb4 (or it's predicate) would be wrong.  If our control dependence machinery
doesn't figure out that cdep(bb4) = {bb5,bb9}, then that would be the bug.

(I haven't checked what our cdep calculation gives as result here, the above is
what should have happened).

  parent reply	other threads:[~2021-02-25 18:29 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 [this message]
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
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-Dge4H4CbwL@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: link
Be 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).