public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tamar Christina <Tamar.Christina@arm.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Richard Biener <rguenther@suse.de>,
	"jakub@redhat.com" <jakub@redhat.com>,  nd <nd@arm.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: RE: [PATCH 2/2]middle-end: Support recognition of three-way max/min.
Date: Wed, 3 Aug 2022 08:17:11 +0000	[thread overview]
Message-ID: <VI1PR08MB532510F8622E115649F5455CFF9C9@VI1PR08MB5325.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <CAFiYyc0FLa9V7xD0tiBLBn-V++iV1GwWUnNTFV7F+bB_-7EfxQ@mail.gmail.com>


> -----Original Message-----
> From: Richard Biener <richard.guenther@gmail.com>
> Sent: Tuesday, August 2, 2022 10:11 AM
> To: Tamar Christina <Tamar.Christina@arm.com>
> Cc: Richard Biener <rguenther@suse.de>; jakub@redhat.com; nd
> <nd@arm.com>; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH 2/2]middle-end: Support recognition of three-way
> max/min.
> 
> On Tue, Aug 2, 2022 at 10:33 AM Tamar Christina via Gcc-patches <gcc-
> patches@gcc.gnu.org> wrote:
> >
> > > > > > When this function replaces the edge it doesn't seem to update
> > > > > > the
> > > > > dominators.
> > > > > > Since It's replacing the middle BB we then end up with an
> > > > > > error
> > > > > >
> > > > > > gcc/testsuite/gcc.dg/tree-ssa/minmax-14.c:17:1: error:
> > > > > > dominator of 5 should be 4, not 2
> > > > > >
> > > > > > during early verify. So instead, I replace the BB but defer
> > > > > > its deletion until cleanup which removes it and updates the
> dominators.
> > > > >
> > > > > Hmm, for a diamond shouldn't you replace
> > > > >
> > > > >   if (EDGE_SUCC (cond_block, 0)->dest == bb)
> > > > >     edge_to_remove = EDGE_SUCC (cond_block, 1);
> > > > >   else
> > > > >     edge_to_remove = EDGE_SUCC (cond_block, 0);
> > > > >
> > > > > with
> > > > >
> > > > >   if (EDGE_SUCC (cond_block, 0)->dest == bb)
> > > > >     edge_to_remove = EDGE_SUCC (cond_block, 1);
> > > > >   else if (EDGE_SUCC (cond_block, 1)->dest == bb)
> > > > >     edge_to_remove = EDGE_SUCC (cond_block, 0);
> > > > >
> > > > > thus, the code expects to be left with a fallthru to the PHI
> > > > > block which is expected to have the immediate dominator being
> > > > > cond_block but with a diamond there's a (possibly empty) block
> > > > > inbetween and dominators are wrong.
> > > >
> > > > Agreed, but the (EDGE_SUCC (cond_block, 1)->dest == bb) doesn't
> > > > seem like the Right one since for a diamond there will be a block
> > > > in between the two.  Did you perhaps mean  EDGE_SUCC (EDGE_SUCC
> > > > (cond_block, 1)->dest, 0)->dest == bb? i.e. that that destination
> > > > across the
> > > diamond be bb, and then you remove the middle block?
> > >
> > > Hmm, I think my condition was correct - the code tries to remove the
> > > edge to the middle-block and checks the remaining edge falls through
> > > to the merge block.  With a true diamond there is no fallthru to the
> > > merge block to keep so we better don't remove any edge?
> > >
> > > > For the minmax diamond we want both edges removed, since all the
> > > > code in the middle BBs are now dead.  But this is probably not
> > > > true in the general
> > > sense.
> >
> > Ah! Sorry I was firing a few cylinders short, I get what you mean now:
> >
> > @@ -425,8 +439,19 @@ replace_phi_edge_with_variable (basic_block
> cond_block,
> >    edge edge_to_remove;
> >    if (EDGE_SUCC (cond_block, 0)->dest == bb)
> >      edge_to_remove = EDGE_SUCC (cond_block, 1);
> > -  else
> > +  else if (EDGE_SUCC (cond_block, 1)->dest == bb)
> >      edge_to_remove = EDGE_SUCC (cond_block, 0);
> > +  else
> > +    {
> > +      /* If neither edge from the conditional is the final bb
> > +        then we must have a diamond block, in which case
> > +        the true edge was changed by SET_USE above and we must
> > +        mark the other edge as the false edge.  */
> > +      gcond *cond = as_a <gcond *> (last_stmt (cond_block));
> > +      gimple_cond_make_false (cond);
> > +      return;
> > +    }
> > +
> 
> Note there is already
> 
>   if (EDGE_COUNT (edge_to_remove->dest->preds) == 1)
>     {
> ...
>     }
>   else
>     {
>       /* If there are other edges into the middle block make
>          CFG cleanup deal with the edge removal to avoid
>          updating dominators here in a non-trivial way.  */
>       gcond *cond = as_a <gcond *> (last_stmt (cond_block));
>       if (edge_to_remove->flags & EDGE_TRUE_VALUE)
>         gimple_cond_make_false (cond);
>       else
>         gimple_cond_make_true (cond);
>     }
> 
> I'm not sure how you can say 'e' is always the true edge?  May I suggest to
> amend the first condition with edge_to_remove && (and initialize that to
> NULL) and use e->flags instead of edge_to_remove in the else, of course
> also inverting the logic since we're keeping 'e'?

As discussed on IRC, here's the version using keep_edge:

@@ -422,12 +436,17 @@ replace_phi_edge_with_variable (basic_block cond_block,
   SET_USE (PHI_ARG_DEF_PTR (phi, e->dest_idx), new_tree);

   /* Remove the empty basic block.  */
-  edge edge_to_remove;
+  edge edge_to_remove = NULL, keep_edge = NULL;
   if (EDGE_SUCC (cond_block, 0)->dest == bb)
     edge_to_remove = EDGE_SUCC (cond_block, 1);
-  else
+  else if (EDGE_SUCC (cond_block, 1)->dest == bb)
     edge_to_remove = EDGE_SUCC (cond_block, 0);
-  if (EDGE_COUNT (edge_to_remove->dest->preds) == 1)
+  else if ((keep_edge = find_edge (cond_block, e->src)))
+    ;
+  else
+    gcc_unreachable ();
+
+  if (edge_to_remove && EDGE_COUNT (edge_to_remove->dest->preds) == 1)
     {
       e->flags |= EDGE_FALLTHRU;
       e->flags &= ~(EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
@@ -438,6 +457,18 @@ replace_phi_edge_with_variable (basic_block cond_block,
       gsi = gsi_last_bb (cond_block);
       gsi_remove (&gsi, true);
     }
+  else if (keep_edge)
+    {
+      /* If we're in a diamond then we have identified the edge
+        that we want to keep.  Since the dominators will require
+        updating in a non-trivial way we leave it to CFG cleanup
+        but mark the condition as appropriately true/false.  */
+      gcond *cond = as_a <gcond *> (last_stmt (cond_block));
+      if (keep_edge->flags & EDGE_FALSE_VALUE)
+       gimple_cond_make_false (cond);
+      else if (keep_edge->flags & EDGE_TRUE_VALUE)
+       gimple_cond_make_true (cond);
+    }
   else
     {
       /* If there are other edges into the middle block make
@@ -1733,15 +1764,52 @@ value_replacement (basic_block cond_bb, basic_block middle_bb,
   return 0;
 }

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

Ok with change?

Thanks,
Tamar

> 
> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> >
> > Ok with this Change?
> >
> > Thanks,
> > Tamar

  reply	other threads:[~2022-08-03  8:17 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-16 11:08 [PATCH 1/2]middle-end: Simplify subtract where both arguments are being bitwise inverted Tamar Christina
2022-06-16 11:09 ` [PATCH 2/2]middle-end: Support recognition of three-way max/min Tamar Christina
2022-06-20  8:36   ` Richard Biener
2022-06-20  9:01     ` Tamar Christina
2022-06-21 13:15       ` Richard Biener
2022-06-21 13:42         ` Tamar Christina
2022-06-27  7:52           ` Richard Biener
2022-07-05 15:25     ` Tamar Christina
2022-07-12  9:39       ` Tamar Christina
2022-07-12 13:19       ` Richard Biener
2022-07-27 10:40         ` Tamar Christina
2022-07-27 11:18           ` Richard Biener
2022-08-02  8:32             ` Tamar Christina
2022-08-02  9:11               ` Richard Biener
2022-08-03  8:17                 ` Tamar Christina [this message]
2022-08-03  8:25                   ` Richard Biener
2022-08-03 20:41                     ` H.J. Lu
2022-06-20 23:16   ` Andrew Pinski
2022-06-21  6:54     ` Richard Biener
2022-06-21  7:12     ` Tamar Christina
2022-06-20  8:03 ` [PATCH 1/2]middle-end: Simplify subtract where both arguments are being bitwise inverted Richard Biener
2022-06-20  8:18   ` Richard Sandiford
2022-06-20  8:49     ` Tamar Christina
2022-06-21  7:43       ` Richard Biener
2022-08-03 15:13         ` Tamar Christina
2022-08-04  6:58           ` Richard Biener

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=VI1PR08MB532510F8622E115649F5455CFF9C9@VI1PR08MB5325.eurprd08.prod.outlook.com \
    --to=tamar.christina@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=nd@arm.com \
    --cc=rguenther@suse.de \
    --cc=richard.guenther@gmail.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).