From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94121 invoked by alias); 15 Dec 2015 16:21:51 -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 94031 invoked by uid 89); 15 Dec 2015 16:21:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Dec 2015 16:21:42 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AAD7D5F0; Tue, 15 Dec 2015 08:21:16 -0800 (PST) Received: from [10.2.206.200] (e100706-lin.cambridge.arm.com [10.2.206.200]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 20D943F459; Tue, 15 Dec 2015 08:21:39 -0800 (PST) Message-ID: <56703E12.40705@foss.arm.com> Date: Tue, 15 Dec 2015 16:21: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: Bernd Schmidt , GCC Patches CC: Segher Boessenkool Subject: Re: [PATCH][combine] PR rtl-optimization/68651 Try changing rtx from (r + r) to (r << 1) to aid recognition References: <566EB527.6070305@foss.arm.com> <56702223.80702@redhat.com> In-Reply-To: <56702223.80702@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-12/txt/msg01493.txt.bz2 Hi Bernd, On 15/12/15 14:22, Bernd Schmidt wrote: > On 12/14/2015 01:25 PM, Kyrill Tkachov wrote: >> PR 68651 is a code quality regression for GCC 5 and GCC 6 that was >> introduced due to updated rtx costs >> for -mcpu=cortex-a53 that affected expansion. The costs changes were >> correct (to the extent that rtx >> costs have any meaning) and I think this is a deficiency in combine that >> should be fixed. > > Thinking a bit more about this, I'm actually not sure that this isn't a backend problem. IMO the costs could and maybe very well should be represented such that a left shift by 1 and an add have the same cost, and the insn pattern for the > shift should emit the add if it is cheaper. If there are multiple ways of expressing an operation, then how it is represented in RTL is essentially irrelevant to the question of how much it costs. > Then for the shift pattern in the MD file we'd have to dynamically select the scheduling type depending on whether or not the shift amount is 1 and the costs line up? Sounds like going out of our way to work around the fact that either combine or recog does not understand equivalent forms of instructions. I'd be more inclined to follow your suggestion in your first reply (teaching genrecog about equivalent patterns) However, I think that would require a bit more involved surgery in recog/combine whereas this approach reuses the existing change_zero_ext approach which I feel is less intrusive at this stage. The price we pay when trying these substitutions is an iteration over the rtx with FOR_EACH_SUBRTX_PTR. recog gets called only if that iteration actually performed a substitution of x + x into x << 1. Is that too high a price to pay? (I'm not familiar with the performance characteristics of the FOR_EACH_SUBRTX machinery) Thanks, Kyrill > > Bernd >