From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 514193858D1E for ; Wed, 4 Jan 2023 10:47:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 514193858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 304AknGl021293; Wed, 4 Jan 2023 04:46:49 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 304AkmhG021292; Wed, 4 Jan 2023 04:46:48 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 4 Jan 2023 04:46:48 -0600 From: Segher Boessenkool To: "Kewen.Lin" Cc: GCC Patches , David Edelsohn , Peter Bergner Subject: Re: [PATCH] rs6000: Don't use optimize_function_for_speed_p too early [PR108184] Message-ID: <20230104104648.GI25951@gate.crashing.org> References: <197abd1f-081c-3206-4dd5-45f0b098612a@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <197abd1f-081c-3206-4dd5-45f0b098612a@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Jan 04, 2023 at 05:20:14PM +0800, Kewen.Lin wrote: > As Honza pointed out in [1], the current uses of function > optimize_function_for_speed_p in rs6000_option_override_internal > are too early, since the query results from the functions > optimize_function_for_{speed,size}_p could be changed later due > to profile feedback and some function attributes handlings etc. > > This patch is to move optimize_function_for_speed_p to all the > use places of the corresponding flags, which follows the existing > practices. Maybe we can cache it somewhere at an appropriate > timing, but that's another thing. > @@ -25604,7 +25602,9 @@ rs6000_call_aix (rtx value, rtx func_desc, rtx tlsarg, rtx cookie) > > /* Can we optimize saving the TOC in the prologue or > do we need to do it at every call? */ > - if (TARGET_SAVE_TOC_INDIRECT && !cfun->calls_alloca) > + if (TARGET_SAVE_TOC_INDIRECT > + && !cfun->calls_alloca > + && optimize_function_for_speed_p (cfun)) > cfun->machine->save_toc_in_prologue = true; Is this correct? If so, it really needs a separate testcase. The rest looks good. Thanks! Segher