From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118285 invoked by alias); 9 Dec 2015 17:32:30 -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 118271 invoked by uid 89); 9 Dec 2015 17:32:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_50,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) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Dec 2015 17:32:27 +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-17-kHTQojI3RM6w_kHXDj8mEQ-1; Wed, 09 Dec 2015 17:32:22 +0000 Received: from [10.2.206.200] ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2015 17:32:22 +0000 Message-ID: <566865A6.4020307@arm.com> Date: Wed, 09 Dec 2015 17:32:00 -0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Christian Bruel , ramana.radhakrishnan@foss.arm.com, gcc-patches@gcc.gnu.org Subject: Re: [PATCH, ARM] PR68674 Fix LTO support for neon builtins and error catching References: <5666D2BC.5030105@st.com> In-Reply-To: <5666D2BC.5030105@st.com> X-MC-Unique: kHTQojI3RM6w_kHXDj8mEQ-1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg01039.txt.bz2 Hi Christian, On 08/12/15 12:53, Christian Bruel wrote: > Hi, > > The order of the NEON builtins construction has led to complications sinc= e 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 b= etween fpu=20 > configurations or when used with LTO. > > Firstly the builtin functions was not initialized before the parsing of f= unctions, leading to wrong type initializations. > > Then error catching code when a builtin was used without the proper fpu f= lags was incomprehensible for the user, for instance > > #include "arm_neon.h" > > int8x8_t a, b; > int16x8_t e; > > void > main() > { > e =3D (int16x8_t)__builtin_neon_vaddlsv8qi (a, b); > } > > compiled with default options (without -mfpu=3Dneon -mfloat-abi=3Dhard) g= ave 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, (int64x= 2_t) __b, __c); > ^~~~~~ > ... > ... and one for each arm_neon.h lines.. > > by postponing the check into arm_expand_builtin, we now emit something mo= re useful: > > testo.c: In function 'main': > testo.c:9:7: error: '__builtin_neon_vaddlsv8qi' neon builtin is not suppo= rted in this configuration. > e =3D (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=20 > pre-approved if the memory is an issue) > > tested without new failures with {,-mfpu=3Dvfp,-mfpu=3Dneon}{,-march=3Dar= mv7-a\} > (a few tests that was fail are now unsupported) > I agree, the vector types (re)initialisation is a tricky part. I've seen similar issues in the aarch64 work for target attributes bool arm_vector_mode_supported_p (machine_mode mode) { - /* Neon also supports V2SImode, etc. listed in the clause below. */ - if (TARGET_NEON && (mode =3D=3D V2SFmode || mode =3D=3D V4SImode || mode= =3D=3D V8HImode + if (mode =3D=3D V2SFmode || mode =3D=3D V4SImode || mode =3D=3D V8HImode || mode =3D=3D V4HFmode || mode =3D=3D V16QImode || mode =3D=3D V4S= Fmode - || mode =3D=3D V2DImode || mode =3D=3D V8HFmode)) - return true; - - if ((TARGET_NEON || TARGET_IWMMXT) - && ((mode =3D=3D V2SImode) - || (mode =3D=3D V4HImode) - || (mode =3D=3D V8QImode))) + || mode =3D=3D V2DImode || mode =3D=3D V8HFmode + || mode =3D=3D V2SImode || mode =3D=3D V4HImode || mode =3D=3D V8QIm= ode) return true; =20=20 So this allows vector modes unconditionally for all targets/fpu configurati= ons? I was tempted to do that in aarch64 when I was encountering similar issues. In the end what worked for me was re-laying out the vector types in SET_CUR= RENT_FUNCTION if necessary (https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01084.html) Kyrill