From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 159213858408 for ; Tue, 14 Sep 2021 07:30:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 159213858408 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id C6FD3200CD; Tue, 14 Sep 2021 07:30:42 +0000 (UTC) Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (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 C1283A3B88; Tue, 14 Sep 2021 07:30:42 +0000 (UTC) Date: Tue, 14 Sep 2021 09:30:42 +0200 (CEST) From: Richard Biener To: Xionghu Luo cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] tree-optimization/102155 - fix LIM fill_always_executed_in CFG walk In-Reply-To: <6e03654b-be4c-db99-dedb-889a33819173@linux.ibm.com> Message-ID: References: <47so1129-4rp-93pp-op88-4p649p42po80@fhfr.qr> <4a364fc3-7390-d3ca-5e71-6520061cf738@linux.ibm.com> <566e5d26-2c0e-8181-2249-211ebf369b73@linux.ibm.com> <8on1r65r-n4qr-9555-s3q6-75783p6622@fhfr.qr> <44039d9b-d481-2a11-fcdc-493915833ae9@linux.ibm.com> <6e03654b-be4c-db99-dedb-889a33819173@linux.ibm.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.9 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.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: Tue, 14 Sep 2021 07:30:47 -0000 On Tue, 14 Sep 2021, Xionghu Luo wrote: > > > On 2021/9/13 16:17, Richard Biener wrote: > > [...] > > I don't understand - BB6 is the header block of loop 2 which is > > always entered and thus BB6 is always executed at least once. > > > > The important part is that BB4 which follows the inner loop is > > _not_ always executed because we don't know if we will exit the > > inner loop. > > > > What am I missing? > > Oh, I see. I only noticed the functionality change of the patch on the case > and no failure check of it, misunderstood it was a regression instead of an > improvement to also hoisting invariants from infinite loop, sorry about that. > > Finally, the function fill_always_executed_in_1 could mark all ALWAYS_EXECUTED > bb both including and after all subloops' bb but break after exiting from > infinite subloops with better performance, thanks. The only thing to be > worried is replacing get_loop_body_in_dom_order makes the code a bit more > complicated for later readers as the loop depth and DOM order is not a problem > here any more? ;) Yeah, but embedding the DOM walk _does_ improve the runtime of the code and it would in principle allow to avoid entering conditionally executed loops that do not always terminate (that's something we could pre-compute and propagate up the loop tree). It's just it didn't seem worth adding even more code given I couldn't make the function pop up on the radar... Richard.