public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steven Bosscher <stevenb.gcc@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Fix CDDCE miscompilation (PR tree-optimization/55018)
Date: Mon, 22 Oct 2012 20:31:00 -0000	[thread overview]
Message-ID: <CABu31nM6aNYnhLrU2WyWDjAM6pnSiwosyEp4Xb=+TE+pyj5RWA@mail.gmail.com> (raw)
In-Reply-To: <20121022195826.GH1752@tucnak.redhat.com>

On Mon, Oct 22, 2012 at 9:58 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Oct 22, 2012 at 09:48:16PM +0200, Steven Bosscher wrote:
>> On Mon, Oct 22, 2012 at 9:35 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > On the following testcase we have two endless loops before cddce2:
>> >
>> > Sender_signal (int Connect)
>> > {
>> >   int State;
>> >   unsigned int occurrence;
>> >
>> >   <bb 2>:
>> >   if (Connect_6(D) != 0)
>> >     goto <bb 8>;
>> >   else
>> >     goto <bb 7>;
>> >
>> >   <bb 3>:
>> >   # occurrence_8 = PHI <0(7), occurrence_12(4)>
>> >   occurrence_12 = occurrence_8 + 1;
>> >   __builtin_printf ("Sender_Signal occurrence %u\n", occurrence_12);
>> >
>> >   <bb 4>:
>> >   goto <bb 3>;
>> >
>> >   <bb 5>:
>> >
>> >   <bb 6>:
>> >   goto <bb 5>;
>> >
>> >   <bb 7>:
>> >   goto <bb 3>;
>> >
>> >   <bb 8>:
>> >   goto <bb 5>;
>> >
>> > }
>> >
>> > The problem are the two empty bbs on the path from the conditional
>> > at the end of bb2 and the endless loops (i.e. bb7 and bb8).
>> > In presence of infinite loops dominance.c adds fake edges to exit pretty
>> > arbitrarily (it uses FOR_EACH_BB_REVERSE and for unconnected bbs
>> > computes post-dominance and adds fake edges to exit), so with the above
>> > testcases both bb7 and bb8 have exit block as immediate post-dominator,
>> > so find_control_dependence stops at those bb's when starting from the
>> > 2->7 resp. 2->8 edges.  bb7/bb8 don't have a control stmt at the end,
>> > so mark_last_stmt_necessary doesn't mark any stmt as necessary in them
>> > and thus if (Connect_6(D) != 0) GIMPLE_COND is never marked as necessary
>> > and the whole endless loop with printfs in it is removed.
>>
>> I'm not sure I'm following this alright, but AFAICT bb7 and bb8 are
>> control-dependent on the "if" in bb2. To preserve the infinite-loop
>> semantics the control parent of the infinite loop must be inherently
>> preserved (because empty infinite loops can't mark any feeding
>> statements). So shouldn't the code in find_obviously_necessary_stmts
>> that handles infinite loops mark the last statement of control parents
>> necessary?
>
> If bb7 and bb8 aren't there and bb2 branches directly to bb3 and bb5,
> then things work correctly, find_control_dependence then says that
> the 2->3 edge is control parent of bb3 and bb4 (bb3 immediate post-dominator
> is bb4, bb4 is immediately post-dominated through fake edge by exit) and
> similarly 2->5 edge is control parent of bb5 and bb6.  Then
> find_obviously_necessary_stmts does:
>       FOR_EACH_LOOP (li, loop, 0)
>         if (!finite_loop_p (loop))
>           {
>             if (dump_file)
>               fprintf (dump_file, "can not prove finiteness of loop %i\n", loop->num);
>             mark_control_dependent_edges_necessary (loop->latch, el, false);
>           }
> and that marks the control stmt in bb2 as necessary, because edge 2->3 is
> in bb3 and bb4 bitmap and edge 2->5 is in bb5 and bb6 control dependence
> bitmap.  The problem with bb7/bb8 is that because they have fake edges to
> exit too, find_control_dependence stops at them, thus 2->7 is considered
> control parent of bb7 and 2->8 control parent of bb8, and 7->3 is considered
> control parent of bb3 and bb4 and 8->5 of bb5 and bb6.  Thus,
> mark_control_dependent_edges_necessary called on say the bb4 latch calls
> marks_last_stmt_necessary on bb7, but, there is no last stmt in that bb,
> nothing to mark necessary and it silently stops there.
>
> What my patch does is change it so that in that case it doesn't stop there,
> but recurses.

I understand what your patch does, but I don't understand why it is correct.

Why are there fake edges from bb7 and bb8 to exit when both are
reverse-reachable from exit via the infinite loops? The infinite loops
should be connected to exit, and bb7 and bb8 should be found by the
DFS from the really dead ends in the cfg.

Ciao!
Steven

  reply	other threads:[~2012-10-22 20:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-22 19:48 Jakub Jelinek
2012-10-22 20:00 ` Steven Bosscher
2012-10-22 20:28   ` Jakub Jelinek
2012-10-22 20:31     ` Steven Bosscher [this message]
2012-10-22 21:09       ` Jakub Jelinek
2012-10-22 21:19         ` Steven Bosscher
2012-10-22 21:50           ` Jakub Jelinek
2012-10-22 21:58             ` Steven Bosscher
2012-10-23  2:43             ` Steven Bosscher
2012-10-23  9:10               ` Jakub Jelinek
2012-10-28 20:11             ` Steven Bosscher
2012-10-29 14:17               ` Richard Biener
2012-11-01 20:26               ` Hans-Peter Nilsson
2012-11-01 20:59                 ` Jakub Jelinek
2012-11-01 21:28                   ` Jan Hubicka

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='CABu31nM6aNYnhLrU2WyWDjAM6pnSiwosyEp4Xb=+TE+pyj5RWA@mail.gmail.com' \
    --to=stevenb.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /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).