From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93613 invoked by alias); 20 Apr 2015 17:51:59 -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 93595 invoked by uid 89); 20 Apr 2015 17:51: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_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; Mon, 20 Apr 2015 17:51:56 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3KHppY0006661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 20 Apr 2015 13:51:52 -0400 Received: from localhost.localdomain (ovpn-113-81.phx2.redhat.com [10.3.113.81]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3KHppaB004951; Mon, 20 Apr 2015 13:51:51 -0400 Message-ID: <55353CB6.1020101@redhat.com> Date: Mon, 20 Apr 2015 17:51: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> <552E86BD.60601@redhat.com> <5534C69B.6070402@arm.com> In-Reply-To: <5534C69B.6070402@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01057.txt.bz2 On 04/20/2015 03:27 AM, Kyrill Tkachov wrote: > > 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. > > So I've thought about it a bit more and I have another concern. The > function returns this: if (choose_mult_variant (mode, coeff, > &algorithm, &variant, max_cost)) return algorithm.cost.cost; else > return max_cost; > > If I read this right, it tries to synthesise the mult at > choose_mult_variant with the limit cost of the reg-by-reg mult, but > if the synthesis cost exceeds that, then it returns the reg-by-reg > mult cost (in return max_cost;) so that can't be right, can it? In the case where the target doesn't have mult imm,reg, then reg*reg would be the right estimated cost if there's no cheap synthesis. It doesn't look like we correctly handle costing on targets with mult imm,reg. jeff