From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74594 invoked by alias); 16 Dec 2015 12:18:47 -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 74578 invoked by uid 89); 16 Dec 2015 12:18:45 -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,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, 16 Dec 2015 12:18:44 +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 (Postfix) with ESMTPS id 89E26693C1; Wed, 16 Dec 2015 12:18:43 +0000 (UTC) Received: from localhost.localdomain (vpn1-6-39.ams2.redhat.com [10.36.6.39]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBGCIgkT012349; Wed, 16 Dec 2015 07:18:42 -0500 Subject: Re: [PATCH][combine] PR rtl-optimization/68651 Try changing rtx from (r + r) to (r << 1) to aid recognition To: Kyrill Tkachov , GCC Patches References: <566EB527.6070305@foss.arm.com> <56702223.80702@redhat.com> <56703E12.40705@foss.arm.com> Cc: Segher Boessenkool From: Bernd Schmidt Message-ID: <567156A1.9040004@redhat.com> Date: Wed, 16 Dec 2015 12:18: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: <56703E12.40705@foss.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg01589.txt.bz2 On 12/15/2015 05:21 PM, Kyrill Tkachov wrote: > 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? Yes. This isn't unusual, take a look at i386.md where you have a lot of switches on attr type to decide which string to print. > 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) It depends on how many of these transforms we are going to try; it also feels very hackish, trying to work around the core design of the combiner. IMO it would be better for machine descriptions to work with the pass rather than against it. If you can somehow arrange for the (plus x x) to be turned into a shift while substituting that might be yet another approach to try. Bernd