public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Aldy Hernandez <aldyh@redhat.com>
Cc: GCC patches <gcc-patches@gcc.gnu.org>, Jeff Law <jeffreyalaw@gmail.com>
Subject: Re: [PATCH] Abstract PHI and forwarder block checks in jump threader.
Date: Mon, 6 Sep 2021 09:19:11 +0200	[thread overview]
Message-ID: <CAFiYyc2aGS0SVu8pcZHbtf1KM1_nEgBHs4skKoxoQ82jyVkKtg@mail.gmail.com> (raw)
In-Reply-To: <20210903135832.735852-1-aldyh@redhat.com>

On Fri, Sep 3, 2021 at 3:59 PM Aldy Hernandez via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> This patch abstracts out a couple common idioms in the forward
> threader that I found useful while navigating the code base.
>
> Tested on x86-64 Linux.
>
> OK?
>
> gcc/ChangeLog:
>
>         * tree-ssa-threadedge.c (has_phis_p): New.
>         (forwarder_block_p): New.
>         (potentially_threadable_block): Call forwarder_block_p.
>         (jump_threader::thread_around_empty_blocks): Call has_phis_p.
>         (jump_threader::thread_through_normal_block): Call
>         forwarder_block_p.
> ---
>  gcc/tree-ssa-threadedge.c | 25 +++++++++++++++++++------
>  1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
> index e57f6d3e39c..3db54a199fd 100644
> --- a/gcc/tree-ssa-threadedge.c
> +++ b/gcc/tree-ssa-threadedge.c
> @@ -95,6 +95,21 @@ jump_threader::thread_through_all_blocks (bool may_peel_loop_headers)
>    return m_registry->thread_through_all_blocks (may_peel_loop_headers);
>  }
>
> +static inline bool
> +has_phis_p (basic_block bb)
> +{
> +  return !gsi_end_p (gsi_start_phis (bb));

gimple_seq_empty_p (phi_nodes (bb)) shoud be cheaper.  Do virtual PHIs
count as PHIs for you?

> +}
> +
> +/* Return TRUE for a forwarder block which is defined as having PHIs
> +   but no instructions.  */
> +
> +static bool
> +forwarder_block_p (basic_block bb)

There exists a function with exactly the same signature in cfgrtl.h, likewise
several similar implementations might exist elsewhere.

Your definition is also quite odd, not matching what one would expect
(the PHI requirement).  The tree-cfgcleanup.c variant has
tree_forwarder_block_p which is explicit about this.

Btw, gsi_start_nondebug_bb does not ignore labels.

> +{
> +  return gsi_end_p (gsi_start_nondebug_bb (bb)) && has_phis_p (bb);
> +}
> +
>  /* Return TRUE if we may be able to thread an incoming edge into
>     BB to an outgoing edge from BB.  Return FALSE otherwise.  */
>
> @@ -107,9 +122,8 @@ potentially_threadable_block (basic_block bb)
>       not optimized away because they forward from outside a loop
>       to the loop header.   We want to thread through them as we can
>       sometimes thread to the loop exit, which is obviously profitable.
> -     the interesting case here is when the block has PHIs.  */
> -  if (gsi_end_p (gsi_start_nondebug_bb (bb))
> -      && !gsi_end_p (gsi_start_phis (bb)))
> +     The interesting case here is when the block has PHIs.  */
> +  if (forwarder_block_p (bb))
>      return true;
>
>    /* If BB has a single successor or a single predecessor, then
> @@ -854,7 +868,7 @@ jump_threader::thread_around_empty_blocks (vec<jump_thread_edge *> *path,
>    /* The key property of these blocks is that they need not be duplicated
>       when threading.  Thus they cannot have visible side effects such
>       as PHI nodes.  */
> -  if (!gsi_end_p (gsi_start_phis (bb)))
> +  if (has_phis_p (bb))
>      return false;
>
>    /* Skip over DEBUG statements at the start of the block.  */
> @@ -994,8 +1008,7 @@ jump_threader::thread_through_normal_block (vec<jump_thread_edge *> *path,
>      {
>        /* First case.  The statement simply doesn't have any instructions, but
>          does have PHIs.  */
> -      if (gsi_end_p (gsi_start_nondebug_bb (e->dest))
> -         && !gsi_end_p (gsi_start_phis (e->dest)))
> +      if (forwarder_block_p (e->dest))
>         return 0;
>
>        /* Second case.  */
> --
> 2.31.1
>

  reply	other threads:[~2021-09-06  7:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-03 13:58 Aldy Hernandez
2021-09-06  7:19 ` Richard Biener [this message]
2021-09-07 10:02   ` Aldy Hernandez
2021-09-07 12:59     ` Richard Biener
2021-09-07 13:23       ` Aldy Hernandez
2021-09-07 15:05         ` Jeff Law
  -- strict thread matches above, loose matches on Subject: below --
2021-09-03 13:56 [PATCH] Improve backwards threader debugging dumps Aldy Hernandez
2021-09-03 13:56 ` [PATCH] Abstract PHI and forwarder block checks in jump threader Aldy Hernandez
2021-09-03 15:00   ` Jeff Law

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=CAFiYyc2aGS0SVu8pcZHbtf1KM1_nEgBHs4skKoxoQ82jyVkKtg@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=aldyh@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@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).