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/99101] optimization bug with -ffinite-loops
Date: Fri, 26 Feb 2021 09:38:30 +0000	[thread overview]
Message-ID: <bug-99101-4-vEMbVqfFDj@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 #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #19)
> (In reply to Michael Matz from comment #18)
> > 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
> 
> ... where _each_ node in that path that isn't bb4 ...  Sorry.
> 
> (Essentially this captures the idea that the path-start node that is the
> control
> node is the _latest_ node that determines (non)execution of the path-end,
> i.e. all
> further nodes after the control node unavoidably pass through path-end).

Yes, bb5 and bb9 are control dependent on bb4.

But nothing in bb5 or bb9 ends up necessary (so the IV 'i' is elminated as
well).
We start with obviously necessary stmts

Marking useful stmt: __builtin_puts (&"1"[0]);

Marking useful stmt: xx.0_1 ={v} xx;

Marking useful stmt: __builtin_abort ();

And the only thing we deem necessary is

Marking useful stmt: if (xx.0_1 != 0)

because we mark this due to the self control-dependence of bb6 to itself
when processing the necessary call.  If we didn't do that we'd end up
optimizing
the testcase to just

int main()
{
  __builtin_puts ("1");
  xx;
  abort ();
}

hmm, actually when removing the if (xx) stmt we end up redirecting the
incoming edge to the loop latch and so we'd produce

  <bb 3> :
  __builtin_puts (&"1"[0]);
  xx.0_1 ={v} xx;
  goto <bb 3>; [100.00%]

because we're using yet another idea of post-dominance, that by
inverted_post_order_compute and it's kludge how to handle backwards
unreachable blocks ... (it produces 7, 5, 9, 0, 2, 12, 3, 11, 4, 6, 1)
At one point the code used to walk immediate post-dominators.  This
was changed for PR65337 in g:e4dbb0d449e778bc810d0d627a5aaefd0d7847b1

  parent reply	other threads:[~2021-02-26  9:38 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 [this message]
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-vEMbVqfFDj@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).