From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 8745C385BF92 for ; Wed, 1 Apr 2020 16:59:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8745C385BF92 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rguenther@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 43B83AB7A; Wed, 1 Apr 2020 16:59:28 +0000 (UTC) Date: Wed, 1 Apr 2020 18:59:27 +0200 (CEST) From: Richard Biener To: Jan Hubicka cc: Jakub Jelinek , gcc-patches@gcc.gnu.org, "Joseph S. Myers" Subject: Re: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++ In-Reply-To: <20200401155632.GB53791@kam.mff.cuni.cz> Message-ID: References: <20200401134709.GK2212@tucnak> <20200401155632.GB53791@kam.mff.cuni.cz> 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=-16.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 01 Apr 2020 16:59:30 -0000 On Wed, 1 Apr 2020, Jan Hubicka wrote: > > On Wed, 1 Apr 2020, Jakub Jelinek wrote: > > > > > On Wed, Apr 01, 2020 at 03:36:30PM +0200, Richard Biener wrote: > > > > @@ -512,7 +512,10 @@ can_inline_edge_by_limits_p (struct cgraph_edge *e, bool report, > > > > /* When devirtualization is disabled for callee, it is not safe > > > > to inline it as we possibly mangled the type info. > > > > Allow early inlining of always inlines. */ > > > > - || (!early && check_maybe_down (flag_devirtualize))) > > > > + || (!early && check_maybe_down (flag_devirtualize)) > > > > + /* It's not safe to inline a function where loops maybe > > > > + infinite into a function where we assume the reverse. */ > > > > + || check_maybe_down (flag_finite_loops)) > > > > { > > > > e->inline_failed = CIF_OPTIMIZATION_MISMATCH; > > > > inlinable = false; > > > > > > Couldn't the above care only if the function has any loops? > > > Otherwise, won't it prevent cross-language LTO inlining too much? > > > Or instead of disabling inlining arrange for a safe flag_finite_loops value > > > for the resulting function (set some flag in cfun of the function that would > > > be considered together with flag_finite_loops (so that we don't have to > > > create further OPTIMIZATION_NODEs) and disable finite loops opts if we've > > > inlined !flag_finite_loops function into flag_finite_loops one)? > > > > I guess I can split out this hunk from the patch - it's a separate > > issue affecting also C++ with mixed option CUs. Yes, ideally we'd > > simply initialize loop->finite_p from flag_finite_loops at CFG > > construction time and then only ever check the flag on the loop > > structure. That would leave us with infinite loops for loops > > we only discover later though. It also opens up the possibility > > of a per-loop #pragma. > > We do want to preserve cross-module inlining between C and C++, so we > really should go with marking the loops pre-inline about finiteness and > try to preserve the info, otherwise we are going to lose quite some > optimizations. OK, I'll update the patch accordingly. Richard.