From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id BC95B384A887 for ; Thu, 9 Sep 2021 15:07:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BC95B384A887 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-261-jAsb9PGcN62F9aJXro1YLw-1; Thu, 09 Sep 2021 11:07:20 -0400 X-MC-Unique: jAsb9PGcN62F9aJXro1YLw-1 Received: by mail-wr1-f70.google.com with SMTP id h1-20020adffd41000000b0015931e17ccfso607455wrs.18 for ; Thu, 09 Sep 2021 08:07:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Yq2kweyEmmm4rwdDK8JIV+QELEePCcjn0619FpvdYEI=; b=Fz1vN//8z3/xnr8YWW7XUXcpVHM19YFVsCYACWMsZ6B7438AjoozEz8wmp0I4Thh3i uSVzQCf2nt+XOc+oVeqCp4T/CxlAxtutOv5jm4UOCkpAVEK8NcEhwXpcJSri9ptorxTG mTjrrZ4bKcXv9zhQFtJPYzfmmAqE5T5BescR0uMiO5NsFcpalMka1QtdiuDo0X3JqUCy NH2CMQlNZ3jDWHz6b9Xm/ayX8ThaKn4VEVsP7ufnpa0vSOj/0Bhl3MgJP3pBoI4ybX3C jPMESUUWyw8wwEQFPsg3V/VONmVqM+Hs0oUB4tNfZO8PC+xPyPA2VjfMtnkErJZ4z+FF qYig== X-Gm-Message-State: AOAM532HOHlkSpySWhX37fAWCMvR75UNdOds6e5XUcSHqKS6Eto8BmvP nVkggoKBTLib9TXGG713i+1wuN0QnO2rgTYejYsxpSN7mmbFzgVhdVK4tRb7AWFzUr3Unnz+AYD RIE2sJow= X-Received: by 2002:a05:600c:210a:: with SMTP id u10mr3470245wml.127.1631200039065; Thu, 09 Sep 2021 08:07:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwjqosj5ks8Ghn3yxPvxicwVFA1xWLlpr8Ib34UifPRo/JDZTH+4+BJ0h+HGT4/OHcaDEF/w== X-Received: by 2002:a05:600c:210a:: with SMTP id u10mr3470221wml.127.1631200038859; Thu, 09 Sep 2021 08:07:18 -0700 (PDT) Received: from abulafia.quesejoda.com ([139.47.33.227]) by smtp.gmail.com with ESMTPSA id l1sm1320194wmq.8.2021.09.09.08.07.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Sep 2021 08:07:17 -0700 (PDT) Subject: Re: More aggressive threading causing loop-interchange-9.c regression To: Michael Matz Cc: Richard Biener , Jeff Law , GCC Mailing List , Andrew MacLeod 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> From: Aldy Hernandez Message-ID: Date: Thu, 9 Sep 2021 17:07:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-13.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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 15:07:23 -0000 On 9/9/21 4:44 PM, Michael Matz wrote: > 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. Sweet. > > (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). Correct. In the backwards threader, we don't start the party if the last block has < 2 succs: FOR_EACH_BB_FN (bb, fun) { if (EDGE_COUNT (bb->succs) > 1) threader.maybe_thread_block (bb); } Thanks. Aldy