public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] Stop backwards thread discovery when leaving a loop
Date: Tue, 16 Aug 2022 12:18:28 +0000 (UTC)	[thread overview]
Message-ID: <20220816121828.abLrCWkFJxoswTEgGaI5_3azoapxda13FKs447JPiBc@z> (raw)

The backward threader copier cannot deal with the situation of
copying blocks belonging to different loops and will reject those
paths late.  The following uses this to prune path discovery,
saving on compile-time.  Note the off-loop block is still considered
as entry edge origin.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

I've split this out from the 'Support threading of just the exit edge'
patch under discussion - it's really an independent change.

Pushed.

	* tree-ssa-threadbackward.cc (back_threader::find_paths_to_names):
	Do not walk further if we are leaving the current loop.
---
 gcc/tree-ssa-threadbackward.cc | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/gcc/tree-ssa-threadbackward.cc b/gcc/tree-ssa-threadbackward.cc
index b886027fccf..1c362839fab 100644
--- a/gcc/tree-ssa-threadbackward.cc
+++ b/gcc/tree-ssa-threadbackward.cc
@@ -355,6 +355,12 @@ back_threader::find_paths_to_names (basic_block bb, bitmap interesting,
 	  || maybe_register_path ()))
     ;
 
+  // The backwards thread copier cannot copy blocks that do not belong
+  // to the same loop, so when the new source of the path entry no
+  // longer belongs to it we don't need to search further.
+  else if (m_path[0]->loop_father != bb->loop_father)
+    ;
+
   // Continue looking for ways to extend the path but limit the
   // search space along a branch
   else if ((overall_paths = overall_paths * EDGE_COUNT (bb->preds))
-- 
2.35.3

             reply	other threads:[~2022-08-16 12:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-16 12:18 Richard Biener [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-08-16 12:18 Richard Biener
2022-08-16 12:18 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=20220816121828.abLrCWkFJxoswTEgGaI5_3azoapxda13FKs447JPiBc@z \
    --to=rguenther@suse.de \
    --cc=gcc-patches@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).