From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56970 invoked by alias); 14 Apr 2015 17:20:12 -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 56960 invoked by uid 89); 14 Apr 2015 17:20:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (207.82.80.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Apr 2015 17:20:10 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by uk-mta-26.uk.mimecast.lan; Tue, 14 Apr 2015 18:20:07 +0100 Received: from [10.2.207.65] ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2015 18:20:07 +0100 Message-ID: <552D4C47.2080206@arm.com> Date: Tue, 14 Apr 2015 17:20:00 -0000 From: Alan Lawrence User-Agent: Thunderbird 2.0.0.24 (X11/20101213) MIME-Version: 1.0 To: Charles Baylis CC: Richard Earnshaw , "gcc-patches@gcc.gnu.org" , Marcus Shawcroft , Tejas Belagod Subject: Re: [PATCH 1/4] vldN_lane error message enhancements (Q registers) References: <1418138874-13285-1-git-send-email-charles.baylis@linaro.org> <1418138874-13285-2-git-send-email-charles.baylis@linaro.org> In-Reply-To: X-MC-Unique: YeQ63uO9T9C-yWwMUqpgjw-1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00696.txt.bz2 That happens in your patch 2/3/4, which use __builtin_aarch64_im_lane_bound= si,=20 indeed. Hence I think the SIMD_ARG_STRUCT_LOAD_STORE_LANE_INDEX approach of= the=20 first patch could well be the right way - initially I thought SIMD_ARG... t= oo=20 heavyweight, but I think I take that back now. Really I think we should clean up and stop using q-reg intrinsics to handle= =20 d-regs here. I'm working on a few patches (i.e. targetting the v{st,ld}{2,3= ,4}*=20 intrinsics) with that aim now, I think I can make some efficiency improveme= nts=20 in the process, too.... --Alan Charles Baylis wrote: > On 14 April 2015 at 14:45, Alan Lawrence wrote: >=20 >> Assuming/hoping that this patch is proposed for new stage 1 ;), >=20 > IIRC the approach of using __builtin_aarch64_im_lane_boundsi doesn't > work (results in double error messages), and so the patch needs to be > rewritten to avoid it. However, thanks for your comments, I'll reflect > those in the next version of the patch. >=20 > Thanks > Charles >=20