From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id BE6C33857C74 for ; Wed, 8 Sep 2021 13:49:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BE6C33857C74 Received: by mail-ed1-x52b.google.com with SMTP id g21so3036634edw.4 for ; Wed, 08 Sep 2021 06:49:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N952tzRXg6Wx1Iu73tHlYExkLXVhuXoUvFYe1uhYd44=; b=tVQ6K0+qXpSQBHyQnFlr3B3h7VpETbX9k3LJLqAwMWmfE1BfB+r7oOoUVj3FhLr3CS jCDnTMrp7EE88e+HjhcEupo0E2EJEpekI2yYeCN0broPFWDEnAwY9MejGTzqe8XxWEGp YRhY4uEblX+D8D6sGn1MNUmmnsnETPKmxXsqANUYdXCScMHifv+eoCVDeILJILys7rkd LkFBPi2Mjm/7M21qVZS1uvfm6w+YeV+s2wKTmv5Ybbbv3wPT285LIWby4quM4jVijyKS XYDKrI23/f94yQKQC5HC27LHStBEX2GuYKYluDj4tSdyuG6gO5zAwxPmKwpzNwhehNAn NoXg== X-Gm-Message-State: AOAM533140k12ksWn4XFo0MrTCR4tGn4NihFaoi4n0GfUO/XXDSVlBi0 o2AmszloUxQmwIgOuNeyDAiS60mwGseEyf4yKnM= X-Google-Smtp-Source: ABdhPJxGfPcLw9Ad4ikks68tvFqPbdALfJmJBuH4AJpmNoeixBSLDxG+NCJ82nQBeSxV5k5id6XtHIoIxxPzC7qI1pI= X-Received: by 2002:aa7:ca4b:: with SMTP id j11mr4043065edt.342.1631108955809; Wed, 08 Sep 2021 06:49:15 -0700 (PDT) MIME-Version: 1.0 References: <09e48b82-bc51-405e-7680-89a5f08e4e8f@redhat.com> In-Reply-To: From: Richard Biener Date: Wed, 8 Sep 2021 15:49:05 +0200 Message-ID: Subject: Re: More aggressive threading causing loop-interchange-9.c regression To: Aldy Hernandez Cc: Michael Matz , Jeff Law , GCC Mailing List , Andrew MacLeod Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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: Wed, 08 Sep 2021 13:49:18 -0000 On Wed, Sep 8, 2021 at 3:25 PM Aldy Hernandez wrote: > > > It would be helpful to have the patch causing the issue to look at the IL. > > But as Micha said, there needs to be a perfect loop nest for interchange > > to work. > > > > Richard. > > Absolutely! I'm attaching the reduced testcase, as well as the patch. > > The problematic thread shows up in the thread2 dump: > > Checking profitability of path (backwards): bb:3 (4 insns) bb:9 (0 > insns) bb:5 > Control statement insns: 2 > Overall: 2 insns > Registering FSM jump thread: (5, 9) incoming edge; (9, 3) (3, 8) > nocopy; (3, 8) Well, so as Micha said, the threading destroys the outer loop by making it have two entries - we actually _do_ recover from this but it results in a non-empty latch of the outer loop and thus the loop is no longer a perfect nest. The interchange pass has special-sauce to recover from the loop store motion applied but not to handle the kind of loop rotation the jump threading caused. The forward threader guards against this by simply disallowing threadings that involve different loops. As I see the threading done here should be 7->3 (outer loop entry) to bb 8 rather than one involving the backedge. Also note the condition is invariant in the loop and in fact subsumed by the condition outside of the loop and it should have been simplified by VRP after pass_ch but I see there's a jump threading pass inbetween pass_ch and the next VRP which is likely the problem. Why does jump threading not try to simplify a condition before attempting to thread through it? After all ranger should be around? Richard. > Thanks. > Aldy