From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3014 invoked by alias); 12 Jan 2015 13:16:46 -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 3003 invoked by uid 89); 12 Jan 2015 13:16:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f49.google.com Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 12 Jan 2015 13:16:42 +0000 Received: by mail-wg0-f49.google.com with SMTP id n12so19221660wgh.8 for ; Mon, 12 Jan 2015 05:16:39 -0800 (PST) X-Received: by 10.180.74.108 with SMTP id s12mr30973069wiv.28.1421068599829; Mon, 12 Jan 2015 05:16:39 -0800 (PST) Received: from [192.168.0.4] (cpc18-hawk12-2-0-cust86.18-1.cable.virginm.net. [77.100.103.87]) by mx.google.com with ESMTPSA id js5sm10188160wid.11.2015.01.12.05.16.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jan 2015 05:16:38 -0800 (PST) Message-ID: <54B3C935.4020507@gmail.com> Date: Mon, 12 Jan 2015 14:14:00 -0000 From: Andrew Stubbs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: ramrad01@arm.com, Kyrill 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> In-Reply-To: <54999C6B.9040400@codesourcery.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-01/txt/msg00684.txt.bz2 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. > > 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. > > 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? > > Andrew