From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 1E42C3858C20 for ; Wed, 3 Aug 2022 09:58:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1E42C3858C20 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 5233534166; Wed, 3 Aug 2022 09:58:06 +0000 (UTC) Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 431992C141; Wed, 3 Aug 2022 09:58:06 +0000 (UTC) Date: Wed, 3 Aug 2022 09:58:06 +0000 (UTC) From: Richard Biener To: Jan Hubicka cc: Aldy Hernandez , gcc-patches , "MacLeod, Andrew" , Jeff Law Subject: Re: [PATCH] Properly honor param_max_fsm_thread_path_insns in backwards threader In-Reply-To: Message-ID: References: <04261.122080204410800126@us-mta-529.us.mimecast.lan> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Wed, 03 Aug 2022 09:58:27 -0000 On Tue, 2 Aug 2022, Jan Hubicka wrote: > > On Tue, 2 Aug 2022, Aldy Hernandez wrote: > > > > > On Tue, Aug 2, 2022 at 1:45 PM Richard Biener wrote: > > > > > > > > On Tue, 2 Aug 2022, Aldy Hernandez wrote: > > > > > > > > > Unfortunately, this was before my time, so I don't know. > > > > > > > > > > That being said, thanks for tackling these issues that my work > > > > > triggered last release. Much appreciated. > > > > > > > > Ah. But it was your r12-324-g69e5544210e3c0 that did > > > > > > > > - else if (n_insns > 1) > > > > + else if (!m_speed_p && n_insns > 1) > > > > > > > > causing the breakage on the 12 branch. That leads to a simpler > > > > fix I guess. Will re-test and also backport to GCC 12 if successful. > > > > > > Huh. It's been a while, but that looks like a typo. That patch was > > > supposed to be non-behavior changing. > > > > Exactly my thinking so reverting it shouldn't be a reason for > > detailed questions. Now, the contains_hot_bb computation is, > > that one was introduced by Honza in r7-6476-g0f0c2cc3a17efa > > together with the comment and a testcase. > > > > So - Honza, what was the reasoning to look at raw BB counts here > > rather than for example the path entry edge count? > I think the explanation is in the final comment: > /* Threading is profitable if the path duplicated is hot but also > in a case we separate cold path from hot path and permit ptimization > of the hot path later. Be on the agressive side here. In some estcases, > as in PR 78407 this leads to noticeable improvements. */ > > If you have non-threadable hot path threading out cold paths will make > it easier to be optimized since you have fewer meets in the dataflow. I see. It does seem that it would be better handled by tracing the hot path but of course threading the cold path might be cheaper. That said, the cost modeling checks hotness of the threaded path by looking at its exit edge (the one we can optimize statically) but shouldn't hotness of the threaded path be determined by looking at the path entry edge count instead? With inconsistent guessed profile (inconsistent now that we can statically compute the outgoing branch on one of the paths) it's of course all GIGO, but ... I'll leave this alone for now. Still we now have the exceptions of predicted never executed entry/exit to avoid diagnostic fallout. Richard.