From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id B96983858C2C for ; Thu, 9 Sep 2021 14:45:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B96983858C2C Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id A193F201E1; Thu, 9 Sep 2021 14:44:59 +0000 (UTC) Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 98FD2A3C0D; Thu, 9 Sep 2021 14:44:59 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 7B4FF65BC; Thu, 9 Sep 2021 14:44:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 79DB564BA; Thu, 9 Sep 2021 14:44:59 +0000 (UTC) Date: Thu, 9 Sep 2021 14:44:59 +0000 (UTC) From: Michael Matz To: Aldy Hernandez cc: Richard Biener , Jeff Law , GCC Mailing List , Andrew MacLeod Subject: Re: More aggressive threading causing loop-interchange-9.c regression In-Reply-To: <7dad1f1f-98e3-f6c7-8cbd-d01122b72260@redhat.com> Message-ID: References: <09e48b82-bc51-405e-7680-89a5f08e4e8f@redhat.com> <6d5695e4-e4eb-14a5-46a6-f425d1514008@redhat.com> <56bd6a6c-0416-7123-c792-521495d69654@redhat.com> <7dad1f1f-98e3-f6c7-8cbd-d01122b72260@redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2021 14:45:02 -0000 Hello, On Thu, 9 Sep 2021, Aldy Hernandez wrote: > > Here there's no simple latch block to start with (the backedge comes > > directly out of the loop exit block). So my suggested improvement > > (testing if the latch was empty and only then reject the thread), would > > solve this. > > Well, there's the thing. Loop discovery is marking BB5 as the latch, so > it's not getting threaded: Yes, it's a latch, but not an empty one. So the thread would make it just even more non-empty, which might not be a problem anymore. So amending my patch somewhere with a strategic && empty_block_p (latch) and only then rejecting the thread should make this testcase work again. (There's still a catch, though: if this non-empty latch, which is also the exit test block, is threaded through and is followed by actual code, then that code will be inserted onto the back edge, not into the latch block before the exit test, and so also create a (new) non-empty latch. That might or might not create problems downstreams, but not as many as transformaing an empty into a non-empty latch would do; but it could create for instance a second back edge (not in this testcase) and suchlike) > BTW, I'm not sure your check for the non-last position makes a difference: > > > diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c > > index 449232c7715..528a753b886 100644 > > --- a/gcc/tree-ssa-threadbackward.c > > +++ b/gcc/tree-ssa-threadbackward.c > > - threaded_through_latch = true; > > + { > > + threaded_through_latch = true; > > + if (j != 0) > > + latch_within_path = true; > > + if (dump_file && (dump_flags & TDF_DETAILS)) > > + fprintf (dump_file, " (latch)"); > > + } > > } > > If the last position being considered is a simple latch, it only has a simple > outgoing jump. There's no need to thread that. You need a block with >= 2 > succ edges to thread anything. So, you are saying that any candidate thread path wouldn't have the latch in the last position if it were just an empty forwarder? I simply wasn't sure about that, so was conservative and only wanted to reject things I knew where positively bad (namely code in the path following the latch that is in danger of being moved into the latch). Ciao, Michael.