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 BDC323849AEA for ; Fri, 10 May 2024 14:35:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BDC323849AEA 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 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BDC323849AEA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=63.228.1.57 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715351747; cv=none; b=icHC/J2x8sWCOMAURyzEwQMEji9ojdheTj7ggKBZcfLGFvzSjm7r7lfRfV2/c8xeWBaYauHbv4vImM5OlibrjQovbOU32oJIiy+RFzS/B5jicfHI4mLCE2Xt5BWL+hvBi4Ryd49dR2ypagSHWYHJmf7vqg8x7k5WoXYGEZuz/eE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715351747; c=relaxed/simple; bh=ybrXTManHDhN4Y4u6+TGJ180NFLjvq8W3ca7DBBCh34=; h=Date:From:To:Subject:Message-ID:Mime-Version; b=N3HIycekaWB+GH0zPeh7P/do5+BH9ElSS8S9cJgtKy/MZV1dBKknHEh+Ea2iCIC1PB7kDqT56SuCSFRhRD5nzKPr0MFrlV+kDV8JxUrpqS5Y+HY8VvBMlkW9GYpFiMPOiQWDSIuBdR529rTIhSID50TXqwYWUFKfKvGu6sEVZZI= ARC-Authentication-Results: i=1; server2.sourceware.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 44AEYjSi021727; Fri, 10 May 2024 09:34:45 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 44AEYiwF021721; Fri, 10 May 2024 09:34:44 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 10 May 2024 09:34:44 -0500 From: Segher Boessenkool To: Richard Biener Cc: HAO CHEN GUI , gcc-patches , David , "Kewen.Lin" , Peter Bergner , Jeff Law Subject: Re: [PATCH] rtlanal: Correct cost regularization in pattern_cost Message-ID: <20240510143444.GC19790@gate.crashing.org> References: <9b57c474-b33b-4a89-82f2-f9a33b1810df@linux.ibm.com> <20240510090421.GA19790@gate.crashing.org> <20240510105211.GB19790@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 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 Fri, May 10, 2024 at 02:50:56PM +0200, Richard Biener wrote: > But for example a reg-reg move when optimizing for speed could have > a zero associated cost. Sure, but this is the way things always have been. I'm sure there are ways to change things so they become slightly easier to use, but that is not what we have now (or what we ever have had). > You might argue that's a bug since there's > an actual instruction and thus at least a size cost (and decode cost) > but then I've seen too much zero cost stuff in backends (like that > combine PR causing s390 backend making address-cost zero even > though it's just "same cost"). address_cost is something else entirely. Many backends have that set to 0 btw, and that means 0, not "unknown". It means all forms of address in valid machine instructions have the same execution (or size) costs. > IMO give we're dispatching to the rtx_cost hook eventually it needs > documenting there or alternatively catching zero and adjusting its > result there. Of course cost == 0 ? 1 : cost is wrong as it makes > zero vs. one the same cost - using cost + 1 when from rtx_cost > might be more correct, at least preserving relative costs. Most things should not use rtx_cost at all, only insn_cost. Taking the "cost" of any random RTL expression makes no sense at all. Neither conceptually, nor practically: it causes many problems, and solves none. Most things already use only insn_cost, if you have the appropriate hooks implemented in your backend (all one of them even). This is so much easier to use (you only need to recognise some big categories of instructions, for a typical target core, instead of eighty different RTX codes, and the combination of them), and gives way better results. Segher