From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52091 invoked by alias); 19 Jun 2017 14:47:34 -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 52069 invoked by uid 89); 19 Jun 2017 14:47:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy= X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Jun 2017 14:47:31 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 38B5815AD; Mon, 19 Jun 2017 07:47:35 -0700 (PDT) Received: from [10.2.206.52] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3DF7E3F587; Mon, 19 Jun 2017 07:47:34 -0700 (PDT) Subject: Re: [PATCH, GCC/testsuite/ARM] Consistently check for neon in vect effective targets To: Christophe Lyon References: <7281afac-431b-cf38-95d6-8c1fbc8afdce@foss.arm.com> <458bf08d-f7e8-6654-907a-7c12490aa9ac@foss.arm.com> <79423ae5-68f4-2b5e-96dc-790122c4db0c@foss.arm.com> Cc: Kyrill Tkachov , Ramana Radhakrishnan , Richard Earnshaw , "gcc-patches@gcc.gnu.org" From: Thomas Preudhomme Message-ID: <825ecaaa-5f9e-40cf-2736-adf0eff40d68@foss.arm.com> Date: Mon, 19 Jun 2017 14:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg01321.txt.bz2 On 19/06/17 15:31, Christophe Lyon wrote: > On 19 June 2017 at 16:11, Thomas Preudhomme > wrote: >> >> >> On 19/06/17 10:16, Thomas Preudhomme wrote: >>> >>> >>> >>> On 19/06/17 08:41, Christophe Lyon wrote: >>>> >>>> Hi Thomas, >>>> >>>> >>>> On 15 June 2017 at 18:18, Thomas Preudhomme >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Conditions checked for ARM targets in vector-related effective targets >>>>> are inconsistent: >>>>> >>>>> * sometimes arm*-*-* is checked >>>>> * sometimes Neon is checked >>>>> * sometimes arm_neon_ok and sometimes arm_neon is used for neon check >>>>> * sometimes check_effective_target_* is used, sometimes >>>>> is-effective-target >>>>> >>>>> This patch consolidate all of these check into using is-effective-target >>>>> arm_neon and when little endian was checked, the check is kept. >>>>> >>>>> ChangeLog entry is as follows: >>>>> >>>>> *** gcc/testsuite/ChangeLog *** >>>>> >>>>> 2017-06-06 Thomas Preud'homme >>>>> >>>>> * lib/target-supports.exp (check_effective_target_vect_int): >>>>> Replace >>>>> current ARM check by ARM NEON's availability check. >>>>> (check_effective_target_vect_intfloat_cvt): Likewise. >>>>> (check_effective_target_vect_uintfloat_cvt): Likewise. >>>>> (check_effective_target_vect_floatint_cvt): Likewise. >>>>> (check_effective_target_vect_floatuint_cvt): Likewise. >>>>> (check_effective_target_vect_shift): Likewise. >>>>> (check_effective_target_whole_vector_shift): Likewise. >>>>> (check_effective_target_vect_bswap): Likewise. >>>>> (check_effective_target_vect_shift_char): Likewise. >>>>> (check_effective_target_vect_long): Likewise. >>>>> (check_effective_target_vect_float): Likewise. >>>>> (check_effective_target_vect_perm): Likewise. >>>>> (check_effective_target_vect_perm_byte): Likewise. >>>>> (check_effective_target_vect_perm_short): Likewise. >>>>> (check_effective_target_vect_widen_sum_hi_to_si_pattern): >>>>> Likewise. >>>>> (check_effective_target_vect_widen_sum_qi_to_hi): Likewise. >>>>> (check_effective_target_vect_widen_mult_qi_to_hi): Likewise. >>>>> (check_effective_target_vect_widen_mult_hi_to_si): Likewise. >>>>> (check_effective_target_vect_widen_mult_qi_to_hi_pattern): >>>>> Likewise. >>>>> (check_effective_target_vect_widen_mult_hi_to_si_pattern): >>>>> Likewise. >>>>> (check_effective_target_vect_widen_shift): Likewise. >>>>> (check_effective_target_vect_extract_even_odd): Likewise. >>>>> (check_effective_target_vect_interleave): Likewise. >>>>> (check_effective_target_vect_multiple_sizes): Likewise. >>>>> (check_effective_target_vect64): Likewise. >>>>> (check_effective_target_vect_max_reduc): Likewise. >>>>> >>>>> Testing: Testsuite shows no regression when targeting ARMv7-A with >>>>> -mfpu=neon-fpv4 and -mfloat-abi=hard or when targeting Cortex-M3 with >>>>> default FPU and float ABI (soft). Testing was done with both >>>>> compare_tests >>>>> and the updated dg-cmp-results proposed in >>>>> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01030.html >>>>> >>>>> Is this ok for trunk? >>>>> >>>> >>>> I applied your patch on top of r249233, and noticed quite a few changes: >>>> >>>> http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/249233-consistent_neon_check.patch/report-build-info.html >>>> >>>> >>>> Note that "Big-Regression" cases are caused by the fact that there a >>>> are PASS->XPASS and XFAILs disappear with your patch, and many >>>> (3000-4000) PASS disappear. >>>> In that intended? >>> >>> >>> It certainly is not. I'd like to investigate this but the link to results >>> for >>> rev 249233 is broken. Could you provide me with the results you have for >>> that so >>> that I can compare manually? >> >> >> Actually yes it is, at least for the configurations with default (which >> still uses -mfpu=vfp in r249233) or VFP (whatever version) FPU. I've checked >> all the ->NA and ->UNSUPPORTED for the arm-none-linux-gnueabi configuration >> and none of them has a dg directive to select the neon unit (such as >> dg-additional-options ). >> I've also looked at arm-none-linux-gnueabihf configuration with neon FPU and >> there is no regression there. >> >> I therefore think this is all normal and expected. Note that under current >> trunk this should be different because neon-fp16 would be selected instead >> of vfp for default FPU with Cortex-A9. >> > > OK, thanks for checking. So the version you sent on June 15th is OK? Yes. > I can start a validation against current trunk, after Richard's series, > it probably makes sense, doesn't it? I think it'll give cleaner results yes. Note that the one with an explicit -mfpu=vfp* without neon will still have a lot of changes but at least the one with default FPU should be more readable. > > Thanks, > > Christophe > >> Best regards, >> >> Thomas