From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39940 invoked by alias); 3 Nov 2015 11:16:44 -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 39925 invoked by uid 89); 3 Nov 2015 11:16:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_50,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: cam-smtp0.cambridge.arm.com Received: from fw-tnat.cambridge.arm.com (HELO cam-smtp0.cambridge.arm.com) (217.140.96.140) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 03 Nov 2015 11:16:43 +0000 Received: from arm.com (e107456-lin.cambridge.arm.com [10.2.206.78]) by cam-smtp0.cambridge.arm.com (8.13.8/8.13.8) with ESMTP id tA3BGbSC004798; Tue, 3 Nov 2015 11:16:37 GMT Date: Tue, 03 Nov 2015 11:16:00 -0000 From: James Greenhalgh To: Bilyan Borisov Cc: gcc-patches@gcc.gnu.org Subject: Re: [AARCH64][PATCH 2/3] Implementing vmulx_lane NEON intrinsic variants Message-ID: <20151103111636.GB18428@arm.com> References: <563338DC.6060206@foss.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <563338DC.6060206@foss.arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00179.txt.bz2 On Fri, Oct 30, 2015 at 09:31:08AM +0000, Bilyan Borisov wrote: > In this patch from the series, all vmulx_lane variants have been implemented as > a vdup followed by a vmulx. Existing implementations of intrinsics were > refactored to use this new approach. > > Several new nameless md patterns are added that will enable the combine pass to > pick up the dup/fmulx combination and replace it with a proper fmulx[lane] > instruction. > > In addition, test cases for all new intrinsics were added. Tested on targets > aarch64-none-elf and aarch64_be-none-elf. Hi, I have a small style comment below. > > gcc/ > > 2015-XX-XX Bilyan Borisov > > * config/aarch64/arm_neon.h (vmulx_lane_f32): New. > (vmulx_lane_f64): New. > (vmulxq_lane_f32): Refactored & moved. > (vmulxq_lane_f64): Refactored & moved. > (vmulx_laneq_f32): New. > (vmulx_laneq_f64): New. > (vmulxq_laneq_f32): New. > (vmulxq_laneq_f64): New. > (vmulxs_lane_f32): New. > (vmulxs_laneq_f32): New. > (vmulxd_lane_f64): New. > (vmulxd_laneq_f64): New. > * config/aarch64/aarch64-simd.md (*aarch64_combine_dupfmulx1, > VDQSF): New pattern. > (*aarch64_combine_dupfmulx2, VDQF): New pattern. > (*aarch64_combine_dupfmulx3): New pattern. > (*aarch64_combine_vgetfmulx1, VDQF_DF): New pattern. I'm not sure I like the use of 1,2,3 for this naming scheme. Elsewhere in the file, this convention points to the number of operands a pattern requires (for example add3). I think elsewhere in the file we use: "*aarch64_mul3_elt" "*aarch64_mul3_elt_" "*aarch64_mul3_elt_to_128df" "*aarch64_mul3_elt_to_64v2df" Is there a reason not to follow that pattern? Thanks, James