From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id EE9153858416 for ; Thu, 28 Oct 2021 18:33:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EE9153858416 Received: by mail-pl1-x62c.google.com with SMTP id z11so5050739plg.8 for ; Thu, 28 Oct 2021 11:33:36 -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-transfer-encoding :content-language; bh=NKKkM5G8G7Ww9LKHiYLAf898EwHKBtw4oljmwNB1vnA=; b=Al/2kKCMYOe006rq2CAXgMT4Xfb/5U/nPlhNsW5QCYybYHFPXIMPcMK0fb7dJE0JNj ENseMqGU57DPDkRDdhG13eGdaiDnU2n97OQJ3g1O4vEyE8mae37jbyPXShSW0u9jE/6z I18L1DYx4RuVC0EMI9maQQbkLsUi6hH8kQqZYt9kIFg10X6w1aYiy2ZvQ4F/7j3aco6t tID9DUoMDoLMBP3IzCqSdM0t7rTIY52xKA9BgFzLsVx2yLLZ4kwDwvlWv9o/2V9UxM6l tUBz+1R0fPyYjLkF74P/cqIuVvCZUetU6o3Z/w9Eb6BbUq2iu4Q5665ppntOKvtXYEL8 r//g== X-Gm-Message-State: AOAM5323Xo57XMD4ZO9RD4y31hSLSE5cPO9m9q7pJfamiNHhHurNcrJ6 aKPkmN6OB5n/WQeIYs/7qys= X-Google-Smtp-Source: ABdhPJwDS43j5qMsakWYnDQfrSakPz/mmfs5neogwXUux8slBWQCKcArJazfDmTLVWdk3JOsj7+2Lw== X-Received: by 2002:a17:902:f543:b0:141:9c1c:9ead with SMTP id h3-20020a170902f54300b001419c1c9eadmr2734602plf.0.1635446015923; Thu, 28 Oct 2021 11:33:35 -0700 (PDT) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id g8sm4419000pfv.123.2021.10.28.11.33.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Oct 2021 11:33:35 -0700 (PDT) Subject: Re: [PATCH] Remove VRP threader passes in exchange for better threading pre-VRP. To: Aldy Hernandez Cc: GCC patches , Andrew MacLeod References: <20211028152446.522454-1-aldyh@redhat.com> From: Jeff Law Message-ID: Date: Thu, 28 Oct 2021 12:33:34 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211028152446.522454-1-aldyh@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, 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: Thu, 28 Oct 2021 18:33:39 -0000 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. jeff