From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 512303858C39 for ; Fri, 29 Oct 2021 07:30:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 512303858C39 Received: by mail-ed1-x52f.google.com with SMTP id ee16so22467164edb.10 for ; Fri, 29 Oct 2021 00:30:05 -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=VL71hgzM49YCWBU491ky2p7lSBljqTGBEaYE6QpOXVU=; b=0ui9ZsyP41XkTaYcRiDlHsCgjpEuuSXOpv8U0MH/WOjoOodlFBJ9JRPduOnlpsnX4s Hu6NbPstnfpWjlzL5otLyozPr8pzy3F8noW9lSYozG22xQCbUA5WQACQ+BnZTahL/TSh EF5FkYUlkxRJ84eCM8JPSqO6kdI3nl8kyZjQj2UlHTkGz89qPlz5b07RoqfXmEF6TvXE GIEcSxFC6QBJ7zZpZyzPs1IwwoTUOIdMhDuabfxGUrkgDfqDM/fFfBEIu5VvrbNrldcx kf1pZemPmnO7t26T8XSLmHKEnMhxWNeWI4NIkFpfT1tAIwjFxpx7LuN/OaZ8T4hPj3iy rTew== X-Gm-Message-State: AOAM531yXMh32Byd1N/+xQKSn5iXOm0COW9Tz2wbZHXPbIrR4wrumofb tIZtsaGwDdNMQQJS1k9cxjTArKM96HPkhlu01rCnYtVI X-Google-Smtp-Source: ABdhPJxKoLtPvBoRmIhiE4gXOlYD3uxVJBpxot3E296NynNkiqCF81rWeN0F40UpIYBiJ+1tT1345d61b3rSuMKjUh8= X-Received: by 2002:a17:906:c301:: with SMTP id s1mr11320725ejz.56.1635492604374; Fri, 29 Oct 2021 00:30:04 -0700 (PDT) MIME-Version: 1.0 References: <20211028152446.522454-1-aldyh@redhat.com> In-Reply-To: From: Richard Biener Date: Fri, 29 Oct 2021 09:29:53 +0200 Message-ID: Subject: Re: [PATCH] Remove VRP threader passes in exchange for better threading pre-VRP. To: Jeff Law Cc: Aldy Hernandez , GCC patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 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-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: Fri, 29 Oct 2021 07:30:07 -0000 On Thu, Oct 28, 2021 at 8:34 PM Jeff Law via Gcc-patches wrote: > > > > On 10/28/2021 9:24 AM, Aldy Hernandez wrote: > > This patch upgrades the pre-VRP threading passes to fully resolving > > backward threaders, and removes the post-VRP threading passes altogether. > > With it, we reduce the number of threaders in our pipeline from 9 to 7. > > > > This will leave DOM as the only forward threader client. When the ranger > > can handle floats, we should be able to upgrade the pre-DOM threaders to > > fully resolving threaders and kill the embedded DOM threader. > > > > The final numbers are: > > > > prev: # threads in backward + vrp-threaders = 92624 > > now: # threads in backward threaders = 94275 > > Gain: +1.78% > > > > prev: # total threads: 189495 > > now: # total threads: 193714 > > Gain: +2.22% > > > > The numbers are not as great as my initial proposal, but I've > > recently pushed all the work that got us to this point ;-). > > > > And... the total compilation improves by 1.32%! > > > > There's a regression on uninit-pred-7_a.c that I've yet to look at. I > > want to make sure it's not a missing thread. If it is, I'll create a PR > > and own it. > > > > Also, the tree-ssa/phi_on_compare-*.c tests have all regressed. This > > seems to be some special case the forward threader handles that the > > backward threader does not (edge_forwards_cmp_to_conditional_jump*). > > I haven't dug deep to see if this is solveable within our > > infrastructure, but a cursory look shows that even though the VRP > > threader threads this, the *.optimized dump ends with more conditional > > jumps than without the optimization. I'd like to punt on this for > > now, because DOM actually catches this through its lone use of the > > forward threader (I've adjusted the tests). However, we will need to > > address this sooner or later, if indeed it's still improving the final > > assembly. > > > > Even though we have been incrementally stressing all the pieces of this > > intricate puzzle, I do expect fall out. My plan from here until stage1 > > ends is to stop new development in the threader(s), and focus on bug > > fixing and improving the developer's debugging experience. > > > > OK pending another round of tests on x86-64 and ppc64le Linux? > > > > gcc/ChangeLog: > > > > * passes.def: Replace the pass_thread_jumps before VRP* with > > pass_thread_jumps_full. Remove all pass_vrp_threader instances. > > > > libgomp/ChangeLog: > > > > * testsuite/libgomp.graphite/force-parallel-4.c: Adjust for threading changes. > > * testsuite/libgomp.graphite/force-parallel-8.c: Same. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.dg/loop-unswitch-2.c: Adjust for threading changes. > > * gcc.dg/old-style-asm-1.c: Same. > > * gcc.dg/tree-ssa/phi_on_compare-1.c: Same. > > * gcc.dg/tree-ssa/phi_on_compare-2.c: Same. > > * gcc.dg/tree-ssa/phi_on_compare-3.c: Same. > > * gcc.dg/tree-ssa/phi_on_compare-4.c: Same. > > * gcc.dg/tree-ssa/pr20701.c: Same. > > * gcc.dg/tree-ssa/pr21001.c: Same. > > * gcc.dg/tree-ssa/pr21294.c: Same. > > * gcc.dg/tree-ssa/pr21417.c: Same. > > * gcc.dg/tree-ssa/pr21559.c: Same. > > * gcc.dg/tree-ssa/pr21563.c: Same. > > * gcc.dg/tree-ssa/pr49039.c: Same. > > * gcc.dg/tree-ssa/pr59597.c: Same. > > * gcc.dg/tree-ssa/pr61839_1.c: Same. > > * gcc.dg/tree-ssa/pr61839_3.c: Same. > > * gcc.dg/tree-ssa/pr66752-3.c: Same. > > * gcc.dg/tree-ssa/pr68198.c: Same. > > * gcc.dg/tree-ssa/pr77445-2.c: Same. > > * gcc.dg/tree-ssa/pr77445.c: Same. > > * gcc.dg/tree-ssa/ranger-threader-1.c: Same. > > * gcc.dg/tree-ssa/ranger-threader-2.c: Same. > > * gcc.dg/tree-ssa/ranger-threader-4.c: Same. > > * gcc.dg/tree-ssa/ssa-dom-thread-1.c: Same. > > * gcc.dg/tree-ssa/ssa-dom-thread-11.c: Same. > > * gcc.dg/tree-ssa/ssa-dom-thread-12.c: Same. > > * gcc.dg/tree-ssa/ssa-dom-thread-14.c: Same. > > * gcc.dg/tree-ssa/ssa-dom-thread-16.c: Same. > > * gcc.dg/tree-ssa/ssa-dom-thread-2b.c: Same. > > * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Same. > > * gcc.dg/tree-ssa/ssa-thread-14.c: Same. > > * gcc.dg/tree-ssa/ssa-thread-backedge.c: Same. > > * gcc.dg/tree-ssa/ssa-vrp-thread-1.c: Same. > > * gcc.dg/tree-ssa/vrp02.c: Same. > > * gcc.dg/tree-ssa/vrp03.c: Same. > > * gcc.dg/tree-ssa/vrp05.c: Same. > > * gcc.dg/tree-ssa/vrp06.c: Same. > > * gcc.dg/tree-ssa/vrp07.c: Same. > > * gcc.dg/tree-ssa/vrp08.c: Same. > > * gcc.dg/tree-ssa/vrp09.c: Same. > > * gcc.dg/tree-ssa/vrp106.c: Same. > > * gcc.dg/tree-ssa/vrp33.c: Same. > OK. And yes, there will probably be fallout. Fully expected and we'll > deal with it. Btw, in case the "fully resolving" mode is slower than not fully resolving please consider gating it on -fexpensive-optimizations (aka -O2+), thus run the passes in not fully resolving modes at-O1. Btw, there were quite a few big compile-time hogs with the vrp_threader passes, not sure if this solves those. Richard. > jeff >