From: "H.J. Lu" <hjl.tools@gmail.com>
To: Richard Biener <rguenther@suse.de>
Cc: Tamar Christina <Tamar.Christina@arm.com>,
"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 13:41:33 -0700 [thread overview]
Message-ID: <CAMe9rOqK4BxO41Y5-qkQng7c71PNw6+XAA-L5=ZXTwTo+oitKQ@mail.gmail.com> (raw)
In-Reply-To: <nycvar.YFH.7.77.849.2208030825071.4208@jbgna.fhfr.qr>
On Wed, Aug 3, 2022 at 1:26 AM Richard Biener via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On Wed, 3 Aug 2022, Tamar Christina wrote:
>
> >
> > > -----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
>
> I meant to merge the keep_edge and the existing else case by setting
> keep_edge the obvious way in the other two if cases. Sorry for not
> being clear ...
>
> OK with that change.
>
> > @@ -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?
This caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106519
> >
> > Thanks,
> > Tamar
> >
> > >
> > > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> > > >
> > > > Ok with this Change?
> > > >
> > > > Thanks,
> > > > Tamar
> >
>
> --
> Richard Biener <rguenther@suse.de>
> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
> Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
> HRB 36809 (AG Nuernberg)
--
H.J.
next prev parent reply other threads:[~2022-08-03 20:42 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
2022-08-03 8:25 ` Richard Biener
2022-08-03 20:41 ` H.J. Lu [this message]
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='CAMe9rOqK4BxO41Y5-qkQng7c71PNw6+XAA-L5=ZXTwTo+oitKQ@mail.gmail.com' \
--to=hjl.tools@gmail.com \
--cc=Tamar.Christina@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=nd@arm.com \
--cc=rguenther@suse.de \
/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).