From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20691 invoked by alias); 19 Aug 2011 14:17:20 -0000 Received: (qmail 20683 invoked by uid 22791); 19 Aug 2011 14:17:18 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-fx0-f47.google.com (HELO mail-fx0-f47.google.com) (209.85.161.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Aug 2011 14:17:04 +0000 Received: by fxg11 with SMTP id 11so2234013fxg.20 for ; Fri, 19 Aug 2011 07:17:03 -0700 (PDT) Received: by 10.223.61.7 with SMTP id r7mr1364471fah.82.1313763423387; Fri, 19 Aug 2011 07:17:03 -0700 (PDT) Received: from richards-thinkpad.stglab.manchester.uk.ibm.com (gbibp9ph1--blueice3n2.emea.ibm.com [195.212.29.84]) by mx.google.com with ESMTPS id e5sm1676182fah.11.2011.08.19.07.17.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Aug 2011 07:17:02 -0700 (PDT) From: Richard Sandiford To: Hans-Peter Nilsson Mail-Followup-To: Hans-Peter Nilsson ,gcc@gcc.gnu.org, richard.sandiford@linaro.org Cc: gcc@gcc.gnu.org Subject: Re: Just what are rtx costs? References: Date: Fri, 19 Aug 2011 14:17:00 -0000 In-Reply-To: (Hans-Peter Nilsson's message of "Wed, 17 Aug 2011 20:55:18 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg00349.txt.bz2 Hans-Peter Nilsson writes: >> But that hardly seems clean either. Perhaps we should instead make >> the SET_SRC always include the cost of the SET, even for registers, >> constants and the like. Thoughts? > > Seems more of maintaining a wart than an improvement for > consistency. So, to enumerate a few options: 1) Make the cost of a SET source X the same as the cost of (set (psuedo) X). The problem with this is that it seems inconsistent with recursive calls. The cost of a REG in a SET would become COSTS_N_INSNS (1), but the cost of a REG in a PLUS should still be 0 on most targets. (The REG has no cost over and above the PLUS itself.) Similarly, constants in a PLUS should have a cost of 0 if additions by that constant are as cheap as additions by a register. Other constants should have a higher cost. But option (1) would mean that constants in a SET that are as cheap as registers in a SET should have cost COSTS_N_INSNS (1). More expensive constants would have a higher cost. 2) Make the cost of a SET source X relative to the cost of a register source. This too is inconsistent. If an addition is as cheap as a move, the cost of PLUS with an outer code of SET should be 0. But COSTS_N_INSNS (1) still seems the best default for other outer codes, especially if the addition has to be done using a separate instruction. Also, having to subtract COSTS_N_INSNS (1) from the "natural" cost would be a bit error-prone. E.g. if you want the cost of MULT to be the number of cycles it takes, you'd need to use COSTS_N_INSNS (cycles - 1) rather than COSTS_N_INSNS (cycles). 3) Stick to the current approach in the target hook (at least AIUI) and fix up the result to suit whateer interface the middle end is using. This is really a generalisation of the idea in my original message (the one I said wasn't very clean). But perhaps it can be justified by saying that the target hook gives the cost of a _term_. That is, the costs provided by the target for terms are relative to the cost of a register. If the supplied X isn't a term, or isn't a valid term for the outer code, then the hook returns the cost of forcing X into a register. This seems to be approximately what we have now, and is probably the easiest thing for the target to provide. So when taking the cost of: (plus A B) with an outer code of SET, the caller is asking rtlanal.c:rtx_cost for the cost of: (set tmp-reg (plus A B)) And by passing (plus A B) to the target hook, rtx_cost in turn is asking for the cost of: (set tmp-reg2 (plus A B)) (set tmp-reg tmp-reg2) rtx_cost then has the responsibility of "optimising" this sequence into: (set tmp-reg (plus A B)) by deducting COSTS_N_INSNS (1) as appropriate. One side-effect of this is that the target should check for fused operations such as MULT-in-PLUS when it sees the PLUS expression. It shouldn't adjust the cost of MULT down a bit if outer_code is PLUS. But I think that's generally true anyway. When you see a MULT with an outer code of PLUS, you don't know if that PLUS was a SET_SRC or not. You do know when you see the PLUS. Another side-effect is that, if a MEM appears in a context where MEMs are not allowed, the target should give it a cost of COSTS_N_INSNS (1) higher than otherwise, to account for a separate load instruction. But perhaps it should be doing that anyway. Bleh. Maybe there just isn't a good answer here. Richard