From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21897 invoked by alias); 12 Jan 2015 13:50:35 -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 21805 invoked by uid 89); 12 Jan 2015 13:50:34 -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,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: foss-mx-na.foss.arm.com Received: from foss-mx-na.foss.arm.com (HELO foss-mx-na.foss.arm.com) (217.140.108.86) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Jan 2015 13:50:32 +0000 Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8]) by foss-mx-na.foss.arm.com (Postfix) with ESMTP id 06ECA217; Mon, 12 Jan 2015 07:50:28 -0600 (CST) Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com [10.112.81.134]) by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id E459D5FAD7; Mon, 12 Jan 2015 07:50:25 -0600 (CST) Received: from [10.1.209.42] (e105545-lin.cambridge.arm.com [10.1.209.42]) by collaborate-mta1.arm.com (Postfix) with ESMTPS id 1332613F78C; Mon, 12 Jan 2015 07:50:24 -0600 (CST) Message-ID: <54B3D120.8020904@arm.com> Date: Mon, 12 Jan 2015 14:27:00 -0000 From: Ramana Radhakrishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrew Stubbs , Kyrylo Tkachov CC: James Greenhalgh , Richard Earnshaw , "gcc-patches@gcc.gnu.org" Subject: Re: [arm][patch] fix arm_neon_ok check on !arm_arch7 References: <5414B99D.3020202@codesourcery.com> <5416B580.9070208@arm.com> <5416C5C3.8070603@codesourcery.com> <20140923082716.GA28745@arm.com> <547DC637.5060906@arm.com> <547F2646.7020308@mentor.com> <54999C6B.9040400@codesourcery.com> <54B3C935.4020507@gmail.com> In-Reply-To: <54B3C935.4020507@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00685.txt.bz2 Sorry about the slow response- have been on holiday and still catching up on email. On 12/01/15 13:16, Andrew Stubbs wrote: > Ping. > > On 23/12/14 16:46, Andrew Stubbs wrote: >> On 03/12/14 15:03, Andrew Stubbs wrote: >>>> The tools have always allowed us to drop down the arch to >>>> march=armv5te along with using -mfpu=neon. We are now changing command >>>> line behaviour, so an inform in terms of diagnostics to the user would >>>> be useful as it states that we don't really have mfpu=neon generating >>>> neon code any more because of this particular case. If we are to do >>>> this then the original patch is probably not enough as it then doesn't >>>> handle the case of TARGET_VFP3 / TARGET_VFP5 / TARGET_NEON_FP16 / >>>> TARGET_FP16 / TARGET_FPU_ARMV8 etc. etc. etc. >>> >>> I'll take a look at those shortly. >> >> Or, not so shortly. >> Sigh. >> It seems that, on ARM, the arch/CPU setting is basically orthogonal to >> the FPU setting, and the compiler doesn't even try to match the one to >> the other. The assembler does the same. In fact, the testcases that >> James refers to, that have hard-coded -march options, really do emit >> armv4 code with Neon, say, although most probably don't have >> vectorizable code. They only work because they're most likely executed >> on Neon hardware. Yes - though I'm surprised as I run an armv5te soft float only test run once a while on my Sheevaplug and don't see these issues. Maybe others do. >> >> This means that there's no obvious patch to fix the issue, in the >> compiler. It's easy to reject Neon for pre-v7 CPUs, but that has >> consequences, as we've seen. We'd have to have a table of fall-back FPUs >> or something, and that doesn't seem straight-forward (and anyway, I'm >> not sure what values to enter into that table). >> >> So, I've attacked the problem from the other end, and updated the >> compiler check. >> >> OK to commit? In principle ok, but I'd like a comment in there explaining why we've done this. Can you also post under what configurations these have been tested ? Ramana >> >> Andrew >