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 3B87C3851C35 for ; Wed, 16 Sep 2020 23:24:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3B87C3851C35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@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 08GNLxCJ001293; Wed, 16 Sep 2020 18:21:59 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 08GNLw0V001292; Wed, 16 Sep 2020 18:21:58 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 16 Sep 2020 18:21:58 -0500 From: Segher Boessenkool To: Alan Modra Cc: gcc-patches@sourceware.org Subject: Re: [RS6000] rs6000_rtx_costs comment Message-ID: <20200916232158.GG28786@gate.crashing.org> References: <20200915011946.3395-1-amodra@gmail.com> <20200915011946.3395-5-amodra@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200915011946.3395-5-amodra@gmail.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no 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, 16 Sep 2020 23:24:01 -0000 Hi! This took a while to digest, sorry. On Tue, Sep 15, 2020 at 10:49:42AM +0930, Alan Modra wrote: > + 1) Calls from places like optabs.c:avoid_expensive_constant will > + come here with OUTER_CODE set to an operation such as AND with X > + being a CONST_INT or other CONSTANT_P type. This will be compared > + against set_src_cost, where we'll come here with OUTER_CODE as SET > + and X the same constant. This (and similar) reasons are why I still haven't made set_src_cost based on insn_cost -- it is in some places compared to some rtx_cost. > + 2) Calls from places like combine:distribute_and_simplify_rtx are > + asking whether a possibly quite complex SET_SRC can be implemented > + more cheaply than some other logically equivalent SET_SRC. It is comparing the set_src_cost of two equivalent formulations, yeah. This is one place where set_src_cost can be pretty easily replaced by insn_cost (combine uses that in most other places, already, and that was a quite useful change). > + 3) Calls from places like default_noce_conversion_profitable_p will > + come here via seq_cost and pass the pattern of a SET insn in X. The pattern of the single SET in any instruction that is single_set, yeah. > + Presuming the insn is valid and set_dest a reg, rs6000_rtx_costs > + will next see the SET_SRC. The overall cost should be comparable > + to rs6000_insn_cost since the code is comparing one insn sequence > + (some of which may be costed by insn_cost) against another insn > + sequence. Yes. And our rtx_cost misses incredibly many cases, but most common things are handled okay. > + 4) Calls from places like cprop.c:try_replace_reg will come here > + with OUTER_CODE as INSN, and X either a valid pattern of a SET or > + one where some registers have been replaced with constants. The > + replacements may make the SET invalid, for example if > + (set (reg1) (and (reg2) (const_int 0xfff))) > + replaces reg2 as > + (set (reg1) (and (symbol_ref) (const_int 0xfff))) > + then the replacement can't be implemented in one instruction and > + really the cost should be higher by one instruction. However, > + the cost for invalid insns doesn't matter much except that a > + higher cost may lead to their rejection earlier. Yup. This uses set_rtx_cost, which also ideally will use insn_cost one day. > + 5) fwprop.c:should_replace_address puts yet another wrinkle on this > + function, where we prefer an address calculation that is more > + complex yet has the same address_cost. In this case "more > + complex" is determined by having a higher set_src_cost. So for > + example, if we want a plain (reg) address to be replaced with > + (plus (reg) (const)) when possible then PLUS needs to cost more > + than zero here. */ Maybe it helps if you more prominenty mention set_rtx_cost and set_src_cost? Either way, okay for trunk. Thanks! Segher