From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124594 invoked by alias); 15 Apr 2015 15:47:58 -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 124583 invoked by uid 89); 15 Apr 2015 15:47:57 -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_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (207.82.80.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Apr 2015 15:47:56 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by uk-mta-28.uk.mimecast.lan; Wed, 15 Apr 2015 16:47:54 +0100 Received: from [10.2.207.50] ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2015 16:47:53 +0100 Message-ID: <552E8829.7080101@arm.com> Date: Wed, 15 Apr 2015 15:47:00 -0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jeff Law , 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> <552E86BD.60601@redhat.com> In-Reply-To: <552E86BD.60601@redhat.com> X-MC-Unique: I9Hr1kykQ0SxBwdDiPDyqA-1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00771.txt.bz2 On 15/04/15 16:41, Jeff Law wrote: > 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 =3D 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. Ah ok. I had noticed the inconsistency and instead thought that mult_by_coeff_cost was the one that needed fixing. Actually, I'd prefer fixing the expand_mult logic, since that would mean we= wouldn't end up passing a mult-by-immediate rtx to the backend costs, which might not be a = valid rtx for some architectures (arm, for example) and would require special casing in rtx co= sts. > > 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. If we end up preferring to fix the expand_mult logic instead, I'm withdrawing this patch then. withdraw Thanks, Kyrill > > Jeff >