From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58608 invoked by alias); 15 Dec 2015 14:33:48 -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 58564 invoked by uid 89); 15 Dec 2015 14:33:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 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 14:33:46 +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 7D18041D; Tue, 15 Dec 2015 06:33:20 -0800 (PST) Received: from e105689-lin.cambridge.arm.com (e105689-lin.cambridge.arm.com [10.2.207.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 95B683F24D; Tue, 15 Dec 2015 06:33:43 -0800 (PST) Subject: Re: [PATCH][combine] PR rtl-optimization/68651 Try changing rtx from (r + r) to (r << 1) to aid recognition To: Bernd Schmidt , Kyrill Tkachov , GCC Patches References: <566EB527.6070305@foss.arm.com> <56702223.80702@redhat.com> Cc: Segher Boessenkool From: Richard Earnshaw Message-ID: <567024C4.2080208@foss.arm.com> Date: Tue, 15 Dec 2015 14:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56702223.80702@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg01481.txt.bz2 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. > > > Bernd That might be OK if we didn't have to have standard canonicalization, but I think handling all these special cases would make it incredibly complex and fragile to work out the accurate costs of all these patterns. It's also possible that this would explicitly break some other optimization passes (such as the way in which multiplies are synthesised with shift/add operations). R.