From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) by sourceware.org (Postfix) with ESMTPS id 5D2403857C6C for ; Mon, 13 Sep 2021 11:49:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5D2403857C6C Received: by mail-io1-xd31.google.com with SMTP id j18so11617032ioj.8 for ; Mon, 13 Sep 2021 04:49:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mkp0LpjDtsdjvNVTdBGqVaxBDWANqtvVjEDs4KvHwS4=; b=qcLsbDordq0FYCZXKj3tSQk2LsOSsu6DiO0XMp7QG8U0pa8qWzEGfkhFlSNbxRl+KI h6AavlrcVoufS0jU4in4uISKUVEutGjiEymMQqaz65X+7JFEjmygj5Vzlghwj/bPF3FD OK8Cu+6JP0i2I9KGJctNu5RW0T+UN3NenGZtyWVPgZHVUARwmU04M2gkZSNY26D8i8Ak uM82MaNVsRFsXzvH4dkUP3qaKBUajECC5YtxKnwtP5U7+89urnk4p66zoSDoToIiZpgr BwXspLXRLDfvFZVrzB/x7YzyuIBQYa+6ZzYN8rrFeqInOhS0zm2BZBBqjY3EQ9vm7oKZ 0Dyw== X-Gm-Message-State: AOAM533IO0weqMOqD1xsffQ4eCsExYcQe84IrvEZSYoDy5wHgwkJjjL7 RqzVMib37zCwaiiEGiKwJP4rTRjyiCT8O6PPC+M= X-Google-Smtp-Source: ABdhPJzY3eTTJFf40VTx1oTsw3ZXrOw0+FEm85uiZ5/HJymDbhDxhSOnh2DkzbXQL/+D2cv1Rmx9AmGsZBUDHudcHjI= X-Received: by 2002:a6b:dc1a:: with SMTP id s26mr5014938ioc.191.1631533742776; Mon, 13 Sep 2021 04:49:02 -0700 (PDT) MIME-Version: 1.0 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> <8998611b-c229-e1d2-9a7a-770f6d45e582@redhat.com> <78b49eb7-0039-9d3d-e459-8da8beaa7175@gmail.com> In-Reply-To: <78b49eb7-0039-9d3d-e459-8da8beaa7175@gmail.com> From: Christophe Lyon Date: Mon, 13 Sep 2021 13:48:51 +0200 Message-ID: Subject: Re: More aggressive threading causing loop-interchange-9.c regression To: Jeff Law Cc: Aldy Hernandez , Michael Matz , gcc-patches X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, KAM_SHORT, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2021 11:49:05 -0000 On Fri, Sep 10, 2021 at 6:32 PM Jeff Law via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > > > On 9/10/2021 7:53 AM, Aldy Hernandez via Gcc-patches wrote: > > > > > > On 9/10/21 3:16 PM, Michael Matz wrote: > >> Hi, > >> > >> On Fri, 10 Sep 2021, Aldy Hernandez via Gcc-patches wrote: > >> > >>> } > >>> + > >>> + /* Threading through a non-empty latch would cause code to be added > >> > >> "through an *empty* latch". The test in code is correct, though. > > > > Whoops. > > > >> > >> And for the before/after loops flag you added: we have a > >> cfun->curr_properties field which can be used. We even already have a > >> PROP_loops flag but that is set throughout compilation from CFG > >> construction until the RTL loop optimizers, so can't be re-used for what > >> is needed here. But you still could invent another PROP_ value > >> instead of > >> adding a new field in struct function. > > > > Oooo, even better. No inline functions. > > > > Like this? > > Aldy > > > > 0001-Disable-threading-through-latches-until-after-loop-o.patch > > > > From ff25faa8dd8721da9bb4715706c662fc09fd4e8c Mon Sep 17 00:00:00 2001 > > From: Aldy Hernandez > > Date: Thu, 9 Sep 2021 20:30:28 +0200 > > Subject: [PATCH] Disable threading through latches until after loop > > optimizations. > > > > The motivation for this patch was enabling the use of global ranges in > > the path solver, but this caused certain properties of loops being > > destroyed which made subsequent loop optimizations to fail. > > Consequently, this patch's mail goal is to disable jump threading > > involving the latch until after loop optimizations have run. > > > > As can be seen in the test adjustments, we mostly shift the threading > > from the early threaders (ethread, thread[12] to the late threaders > > thread[34]). I have nuked some of the early notes in the testcases > > that came as part of the jump threader rewrite. They're mostly noise > > now. > > > > Note that we could probably relax some other restrictions in > > profitable_path_p when loop optimizations have completed, but it would > > require more testing, and I'm hesitant to touch more things than needed > > at this point. I have added a reminder to the function to keep this > > in mind. > > > > Finally, perhaps as a follow-up, we should apply the same restrictions to > > the forward threader. At some point I'd like to combine the cost models. > > > > Tested on x86-64 Linux. > > > > p.s. There is a thorough discussion involving the limitations of jump > > threading involving loops here: > > > > https://gcc.gnu.org/pipermail/gcc/2021-September/237247.html > > > > gcc/ChangeLog: > > > > * tree-pass.h (PROP_loop_opts_done): New. > > * gimple-range-path.cc (path_range_query::internal_range_of_expr): > > Intersect with global range. > > * tree-ssa-loop.c (tree_ssa_loop_done): Set PROP_loop_opts_done. > > * tree-ssa-threadbackward.c > > (back_threader_profitability::profitable_path_p): Disable > > threading through latches until after loop optimizations have run. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.dg/tree-ssa/ssa-dom-thread-2b.c: Adjust for disabling of > > threading through latches. > > * gcc.dg/tree-ssa/ssa-dom-thread-6.c: Same. > > * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Same. > Hi, This last test now fails on aarch64: FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps threaded: 8" Can you check? Thanks, Christophe OK > jeff > >