From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113229 invoked by alias); 15 Apr 2015 15:42:10 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 113211 invoked by uid 89); 15 Apr 2015 15:42:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 15 Apr 2015 15:42:08 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3FFg3nZ000845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 15 Apr 2015 11:42:03 -0400 Received: from localhost.localdomain ([10.3.113.3]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3FFfnrf025912; Wed, 15 Apr 2015 11:41:49 -0400 Message-ID: <552E86BD.60601@redhat.com> Date: Wed, 15 Apr 2015 15:42:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kyrill Tkachov , GCC Patches , "William J. Schmidt" Subject: Re: [PATCH][expmed] Calculate mult-by-const cost properly in mult_by_coeff_cost References: <5506ACA9.4000909@arm.com> <552C0872.1040803@redhat.com> <552CCAD6.4040200@arm.com> In-Reply-To: <552CCAD6.4040200@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00770.txt.bz2 On 04/14/2015 02:07 AM, Kyrill Tkachov wrote: > Hi Jeff, > > Thanks for looking at this. > > On 13/04/15 19:18, Jeff Law wrote: >> On 03/16/2015 04:12 AM, Kyrill Tkachov wrote: >>> Hi all, >>> >>> Eyeballing the mult_by_coeff_cost function I think it has a typo/bug. >>> It's supposed to return the cost of multiplying by a constant 'coeff'. >>> It calculates that by taking the cost of a MULT rtx by that constant >>> and comparing it to the cost of synthesizing that multiplication, and >>> returning >>> the cheapest. However, in the MULT rtx cost calculations it creates >>> a MULT rtx of two REGs rather than the a REG and the GEN_INT of coeff as >>> I would >>> expect. This patches fixes that in the obvious way. >>> >>> Tested aarch64-none-elf and bootstrapped on x86_64-linux-gnu. >>> I'm guessing this is stage 1 material at this point? >>> >>> Thanks, >>> Kyrill >>> >>> 2015-03-13 Kyrylo Tkachov >>> >>> * expmed.c (mult_by_coeff_cost): Pass CONT_INT rtx to MULT cost >>> calculation rather than fake_reg. >> I'm pretty sure this patch is wrong. >> >> The call you're referring to is computing an upper limit to the cost for >> use by choose_mult_variant. Once a synthesized multiply sequence >> exceeds the cost of reg*reg, then that synthesized sequence can be >> thrown away because it's not profitable. > > But shouldn't the limit be the mult-by-constant cost? No, because ultimately we're trying to do better than just loading the constant into a register and doing a reg * reg. So the reg*reg case is the upper bound for allowed cost of a synthesized sequence. > Consider also similar logic in expand_mult: > max_cost = set_src_cost (gen_rtx_MULT (mode, fake_reg, op1), speed); > if (choose_mult_variant (mode, coeff, &algorithm, &variant, max_cost)) > return expand_mult_const (mode, op0, coeff, target, > &algorithm, variant); This looks wrong to me. They're certainly inconsistent. Maybe start by asking Bill (who added mult_by_coeff_cost and whom I've cc'd) what his intent was to make sure it matches my understanding. Jeff