From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26126 invoked by alias); 22 Aug 2011 23:23:27 -0000 Received: (qmail 26116 invoked by uid 22791); 22 Aug 2011 23:23:25 -0000 X-SWARE-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-wy0-f175.google.com (HELO mail-wy0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 22 Aug 2011 23:23:10 +0000 Received: by wyf19 with SMTP id 19so4457448wyf.20 for ; Mon, 22 Aug 2011 16:23:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.1.9 with SMTP id 9mr2631557wec.2.1314055389245; Mon, 22 Aug 2011 16:23:09 -0700 (PDT) Received: by 10.216.21.136 with HTTP; Mon, 22 Aug 2011 16:23:09 -0700 (PDT) In-Reply-To: <4E513A02.3080009@gjlay.de> References: <4E4BFA40.9050907@gjlay.de> <4E513A02.3080009@gjlay.de> Date: Mon, 22 Aug 2011 23:23:00 -0000 Message-ID: Subject: Re: Just what are rtx costs? From: Peter Bigot To: Georg-Johann Lay Cc: Richard Sandiford , gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00390.txt.bz2 On Sun, Aug 21, 2011 at 12:01 PM, Georg-Johann Lay wrote: > > Richard Sandiford schrieb: >> >> Georg-Johann Lay writes: >> >>> Richard Sandiford schrieb: >>> >>>> I've been working on some patches to make insn_rtx_cost take account >>>> of the cost of SET_DESTs as well as SET_SRCs. =A0But I'm slowly beginn= ing >>>> to realise that I don't understand what rtx costs are supposed to repr= esent. >>>> >>>> AIUI the rules have historically been: >>>> >>>> =A01) Registers have zero cost. >>>> >>>> =A02) Constants have a cost relative to that of registers. =A0By exten= sion, >>>> =A0 =A0constants have zero cost if they are as cheap as a register. >>>> >>>> =A03) With an outer code of SET, actual operations have the cost >>>> =A0 =A0of the associated instruction. =A0E.g. the cost of a PLUS >>>> =A0 =A0is the cost of an addition instruction. >>>> >>>> =A04) With other outer codes, actual operations have the cost >>>> =A0 =A0of the combined instruction, if available, or the cost of >>>> =A0 =A0a separate instruction otherwise. =A0E.g. the cost of a NEG >>>> =A0 =A0inside an AND might be zero on targets that support BIC-like >>>> =A0 =A0instructions, and COSTS_N_INSNS (1) on most others. >>>> >>>> [...] >>>> >>>> But that hardly seems clean either. =A0Perhaps we should instead make >>>> the SET_SRC always include the cost of the SET, even for registers, >>>> constants and the like. =A0Thoughts? >>> >>> IMO a clean approach would be to query the costs of a whole insn (resp.= it's pattern) rather than the cost of an RTX. =A0COSTS_N_INSNS already ind= icates that the costs are compared to *insn* costs i.e. cost of the whole p= attern (modulo clobbers). >> >> The problem is that we sometimes want the cost of something that cannot >> be done using a single instruction. =A0E.g. some CONST_INTs take several >> instructions to create on MIPS. =A0In this case the costs are really >> measuring the cost of an emit_move_insn sequence, not a single insn. >> >> I suppose we could use emit_move_insn to create a temporary sequence >> and sum the cost of each individual instruction. =A0But that's potential= ly >> expensive. > > No, that complexity is not needed. =A0For (set (reg) (const_int)) the BE = can just return the cost of the expanded sequence because it knows how it w= ill be expanded and how much it will cost. =A0There's no need to really exp= and the sequence. > > That's the way, e.g. AVR backend works: Shifts/mul/div must be expanded b= ecause the hardware does not support them natively. =A0The rtx_cost for suc= h an expression (which are always interpreted as RHS of a (set (reg) ...)) = are the sum over the costs of all insns the expander will produce. One of my problems with this approach is that the logic that's put into an expander definition preparation statement (or, in the case of AVR, the function invoked by the insn output statement) gets replicated abstractly in rtx_costs: both places have long switch statements on operand mode and const shift value to determine the instructions that get emitted (in the former) or how many of them there are (in the latter).=A0 How likely is it the two are kept consistent over the years? I'm working on the (not yet pushed upstream) back-end for the TI MSP430, which has some historical relationship to AVR from about a decade ago, and the answer to that question is "not very likely". I've changed the msp430 back-end so that instead of putting all that logic in the output statement for the insn, it goes into a preparation statement for a standard expander.=A0 This way the individual insns that result in (say) a constant shift of 8 bits using xor and bswap are available for the optimizer and register allocator to improve. This works pretty well, but still leaves me with problems when it comes to computing RTX costs, because there seems to be some strength reduction optimization for multiplication that's asking for the costs to shift each integer type by 1 to 15 bits, when in fact no such insn should ever be produced if real code was being generated. I think this is an example of the case Richard's describing. If, in rtx_costs, I could detect an unexpected insn, deduce the correct expander function, call it, then recurse on the sequence it generated, I'd get the right answer---though I'd infinitely prefer not to be asked to calculate the cost of an unexpected insn.=A0 Doing this expansion would probably be very expensive, though, and with the side effects that are part of emit_insn I don't know how to safely call things that invoke it when what gets emitted isn't part of the actual stream. >> >> Also, any change along these lines is similar to the "tie costs to >> .md patterns" thing that I mentioned at the end of the message. >> I don't really have time to work on anything so invasive, so the >> question is really whether we can sensibly change the costs within >> the current framework. >> >>> E.g. the cost of a CONST_INT is meaningless if you don't know what to d= o with the constant. (set (reg:QI) (const_int 0)) might have different cost= than (set (reg:SI) (const_int 0)). >> >> That's the old modeless-CONST_INT problem though. =A0I agree the mode >> makes a difference, but I think it's a separate issue. > > It's the same bottom line: If you see the insn, you know the cost. But can you know it without duplicating all the effort that goes into expanding it? >> If we did pass complete instructions, each caller would have to provide >> a SET whose SET_DEST is an arbitrary psuedo register of the required mod= e. >> In all likelihood, we'd define a new utility function do this for us. >> >> So in the modeless-CONST_INT world, we would need to pass the mode >> to that utility function. =A0But if we're prepared to pass such extra >> information around, we could simply do it by passing the mode directly >> to rtx_cost. >> >> I think the cost of a full rvalue (rather than a complete SET), >> should be based on the assumption that the destination is a register. >> So I don't the backend is missing any information in that respect. >> I.e. the problem doesn't seem to be lack of information, but rather >> lack of consistency (between registers, constants, operators, >> and so on). >> >>> Similar applies for an addition if you don't know if it's for >>> arithmetic or address offset computation inside a MEM. >> >> Yeah, that'd be bad, but I don't think we take costs at that level. >> Only a few places take the cost of anything "smaller" than a complete >> rvalue, and they either take the cost of a condition or take the cost of >> an operand to a "top-level" operator. =A0The target then has the option = of >> stopping the recursion whenever it likes. >> >> Richard > > Johann Peter