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 2EE763858C78 for ; Wed, 23 Feb 2022 21:28:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2EE763858C78 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 21NLRovi018542; Wed, 23 Feb 2022 15:27:50 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 21NLRnNB018541; Wed, 23 Feb 2022 15:27:49 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 23 Feb 2022 15:27:49 -0600 From: Segher Boessenkool To: guojiufu Cc: Richard Biener , gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, jlaw@tachyum.com, wschmidt@linux.ibm.com Subject: Re: [PATCH] Check if loading const from mem is faster Message-ID: <20220223212749.GI614@gate.crashing.org> References: <20220222065313.2040127-1-guojiufu@linux.ibm.com> <70r5oq10-988r-3rns-356-o3s79o292nn0@fhfr.qr> <1d471fba-a966-3e90-92ce-ae4707fe53b6@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1d471fba-a966-3e90-92ce-ae4707fe53b6@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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: Wed, 23 Feb 2022 21:28:53 -0000 On Wed, Feb 23, 2022 at 07:32:55PM +0800, guojiufu wrote: > >We already have TARGET_INSN_COST which you could ask for a cost. > >Like if we'd have a single_set then just temporarily substitute > >the RHS with the candidate and cost the insns and compare against > >the original insn cost. So why exactly do you need a new hook > >for this particular situation? > > Thanks for pointing out this! Segher also mentioned this before. > Currently, CSE is using rtx_cost. Using insn_cost to replace > rtx_cost would be a good idea for all necessary places including CSE. I have updated many places that used rtx_cost to use insn_cost instead, over the years (as a fallback the generic insn_cost will use rtx_cost). CSE is the biggest remaining thing. There is a long tail left as well of course. > For this particular case: check the cost for constants. > I did not use insn_cost. Because to use insn_cost, we may need > to create a recognizable insn temporarily, and for some kind of > constants we may need to create a sequence instructions on some > platform, e.g. "li xx; ori ; sldi .." on ppc64, and check the > sum cost of those instructions. If only create one fake > instruction, the insn_cost may not return the accurate cost either. That is the problem yes. You need insns to call insn_cost on. You can look in combine.c:combine_validate_cost to see how this can be done; but you need to have some code to generate in the first place, and for CSE it isn't always clear what code to generate, it really is based on RTL expressions having a cost. Segher