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 38E8F3858D28 for ; Wed, 23 Feb 2022 21:15:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 38E8F3858D28 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 21NLE7f8017969; Wed, 23 Feb 2022 15:14:07 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 21NLE64I017968; Wed, 23 Feb 2022 15:14:06 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 23 Feb 2022 15:14:06 -0600 From: Segher Boessenkool To: Richard Biener Cc: guojiufu , 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: <20220223211406.GH614@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> <7ns67pr-q7q-rps-136-37pn481515q5@fhfr.qr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ns67pr-q7q-rps-136-37pn481515q5@fhfr.qr> 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:15:10 -0000 On Wed, Feb 23, 2022 at 02:02:59PM +0100, Richard Biener wrote: > I'm assuming we're always dealing with > > (set (reg:MODE ..) ) > > here and CSE is not substituting into random places of an > instruction(?). I don't know what 'rtx_cost' should evaluate > to for a constant, if it should implicitely evaluate the cost > of putting the result into a register for example. rtx_cost is no good here (and in most places). rtx_cost should be 0 for anything that is used as input in a machine instruction -- but you need much more context to determine that. insn_cost is much simpler and much easier to use. > Using RTX_COST with SET and 1 at least looks no worse than using > your proposed new target hook and comparing it with the original > unfolded src (again with SET and 1). It is required to generate valid instructions no matter what, before the pass has finished that is. On all more modern architectures it is futile to think you can usefully consider the cost of an RTL expression and derive a real-world cost of the generated code from that. But there is so much more wrong with cse.c :-( Segher