From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75871 invoked by alias); 19 Oct 2015 16:56:18 -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 75856 invoked by uid 89); 19 Oct 2015 16:56:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 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; Mon, 19 Oct 2015 16:56:17 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-22-BMJvIyy-TSiZc5SFaig2Gg-1; Mon, 19 Oct 2015 17:56:12 +0100 Received: from e105915-lin.cambridge.arm.com ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2015 17:56:12 +0100 Subject: Re: [PATCH 1/3] [ARM] PR63870 Add qualifiers for NEON builtins To: Charles Baylis References: <1444175989-24944-1-git-send-email-charles.baylis@linaro.org> <1444175989-24944-2-git-send-email-charles.baylis@linaro.org> <561B9242.1060506@arm.com> Cc: Kyrylo Tkachov , Ramana Radhakrishnan , "gcc-patches@gcc.gnu.org" From: Alan Lawrence Message-ID: <562520AB.3000108@arm.com> Date: Mon, 19 Oct 2015 16:59: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: X-MC-Unique: BMJvIyy-TSiZc5SFaig2Gg-1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg01773.txt.bz2 On 14/10/15 23:02, Charles Baylis wrote: > On 12 October 2015 at 11:58, Alan Lawrence wrote: > >> Given we are making changes here to how this all works on bigendian, have >> you tested armeb at all? > > I tested on big endian, and it passes, except.... Well, I asked because it seemed good to make sure that the changes/improvem= ents=20 to how lane-swapping was done, wasn't breaking anything on armeb by the bac= k=20 door, and so thank you, I'm happy with that as far as your patch is concern= ed ;). > for a testsuite issue > with the *_f16 tests, which fail because they are built without the > fp16 options on big endian. This is because > check_effective_target_arm_neon_fp16_ok_nocache gets an ICE when it > attempts to compile the test program. I think those fp16 intrinsics > are in your area, do you want to take a look? :) Heh, yes, I see ;). So I've dug into this a bit, and the problem seems to b= e=20 that we don't define a movv4hf pattern, and hence, we fall back to=20 emit_multi_word_move. This uses subregs, and in simplify_subreg_regno,=20 REG_CANNOT_CHANGE_MODE_P is true on bigendian (but false on little-endian). That is, I *think* the right thing to do is just to add a movv4hf (and v8hf= )=20 pattern, I'm testing this now.... Cheers, Alan