From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77017 invoked by alias); 8 Dec 2015 13:29:39 -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 77004 invoked by uid 89); 8 Dec 2015 13:29:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mx07-00178001.pphosted.com Received: from mx08-00178001.pphosted.com (HELO mx07-00178001.pphosted.com) (91.207.212.93) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 08 Dec 2015 13:29:37 +0000 Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx08-00178001.pphosted.com (8.14.5/8.14.5) with SMTP id tB8DSsDv009048; Tue, 8 Dec 2015 14:29:31 +0100 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx08-00178001.pphosted.com with ESMTP id 1ynv29981s-1 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 08 Dec 2015 14:29:31 +0100 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 0036F31; Tue, 8 Dec 2015 13:28:53 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas5.st.com [10.75.90.71]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 673DD4DB1; Tue, 8 Dec 2015 13:29:29 +0000 (GMT) Received: from [164.129.122.197] (164.129.122.197) by webmail-eu.st.com (10.75.90.13) with Microsoft SMTP Server (TLS) id 8.3.389.2; Tue, 8 Dec 2015 14:29:29 +0100 Subject: Re: [PATCH, ARM] PR68674 Fix LTO support for neon builtins and error catching To: Ramana Radhakrishnan References: <5666D2BC.5030105@st.com> CC: Ramana Radhakrishnan , Kyrylo Tkachov , gcc-patches From: Christian Bruel X-No-Archive: yes Message-ID: <5666DB38.4070305@st.com> Date: Tue, 08 Dec 2015 13:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21,1.0.33,0.0.0000 definitions=2015-12-08_08:2015-12-08,2015-12-08,1970-01-01 signatures=0 X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00862.txt.bz2 Hello Ramana, On 12/08/2015 02:01 PM, Ramana Radhakrishnan wrote: > On Tue, Dec 8, 2015 at 12:53 PM, Christian Bruel wrote: >> Hi, >> >> The order of the NEON builtins construction has led to complications since >> the attribute target support. This was not a problem when driven from the >> command line, but was causing various issues when the builtins was mixed >> between fpu configurations or when used with LTO. >> >> Firstly the builtin functions was not initialized before the parsing of >> functions, leading to wrong type initializations. >> >> Then error catching code when a builtin was used without the proper fpu >> flags was incomprehensible for the user, for instance >> >> #include "arm_neon.h" >> >> int8x8_t a, b; >> int16x8_t e; >> >> void >> main() >> { >> e = (int16x8_t)__builtin_neon_vaddlsv8qi (a, b); >> } > > I'm not sure what problem you are trying to solve here - The user > should never be using __builtin_neon_vaddlsv8qi (a, b) here. What > happens with vaddl_s16 intrinsic ? > > They really have to only use the vaddl_s8 intrinsic. Sure, that's not the problem, replace _builtin_neon_vaddlsv8qi by vaddl_s8. The tests (part of the patch) equivalently fails. But anyway, users do use the __builtin directly, see for instance the Bug 65837 > > > Ramana > >> >> compiled with default options (without -mfpu=neon -mfloat-abi=hard) gave >> pages of >> >> /arm-none-eabi/6.0.0/include/arm_neon.h:39:9: error: unknown type name >> '__simd64_int8_t' >> typedef __simd64_int8_t int8x8_t; >> ... >> ... >> arm_neon.h:4724:3: error: can't convert a vector of type 'poly64x2_t {aka >> __vector(4) int}' to type 'int' which has different size >> return (poly64x2_t)__builtin_neon_vsli_nv2di ((int64x2_t) __a, >> (int64x2_t) __b, __c); >> ^~~~~~ >> ... >> ... and one for each arm_neon.h lines.. >> >> by postponing the check into arm_expand_builtin, we now emit something more >> useful: >> >> testo.c: In function 'main': >> testo.c:9:7: error: '__builtin_neon_vaddlsv8qi' neon builtin is not >> supported in this configuration. >> e = (int16x8_t)__builtin_neon_vaddlsv8qi (a, b); >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> One small side effect to note: The total memory allocated is 370k bigger >> when neon is not used, so this support will have a follow-up to make their >> initialization lazy. But I'd like first to stabilize the stuff for stage3 >> (or get it pre-approved if the memory is an issue) >> >> tested without new failures with {,-mfpu=vfp,-mfpu=neon}{,-march=armv7-a\} >> (a few tests that was fail are now unsupported) >> >> OK for trunk ? >> >> >> >> >> >> >> >>