This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][ARM] PR target/71056: Don't use vectorized builtins when NEON is not available
- From: Ramana Radhakrishnan <ramana dot radhakrishnan at foss dot arm dot com>
- To: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Date: Thu, 19 May 2016 14:36:00 +0100
- Subject: Re: [PATCH][ARM] PR target/71056: Don't use vectorized builtins when NEON is not available
- Authentication-results: sourceware.org; auth=none
- References: <5733428B dot 20106 at foss dot arm dot com>
On 11/05/16 15:32, Kyrill Tkachov wrote:
> Hi all,
>
> In this PR a NEON builtin is introduced during SLP vectorisation even when NEON is not available
> because arm_builtin_vectorized_function is missing an appropriate check in the BSWAP handling code.
>
> Then during expand when we try to expand the NEON builtin the code in arm_expand_neon_builtin rightly
> throws an error telling the user to enable NEON, even though the testcase doesn't use any intrinsics.
>
> This patch fixes the bug by bailing out early if !TARGET_NEON. This allows us to remove a redundant
> TARGET_NEON check further down in the function as well.
>
> Bootstrapped and tested on arm-none-linux-gnueabihf.
> Ok for trunk?
>
> This appears on GCC 6 as well.
> On older branches the test failure doesn't trigger but the logic looks buggy anyway.
> Ok for the branches as well if testing is clean?
>
> Thanks,
> Kyrill
>
> 2016-05-11 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
>
> PR target/71056
> * config/arm/arm-builtins.c (arm_builtin_vectorized_function): Return
> NULL_TREE early if NEON is not available. Remove now redundant check
> in ARM_CHECK_BUILTIN_MODE.
>
> 2016-05-11 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
>
> PR target/71056
> * gcc.target/arm/pr71056.c: New test.
OK. LGTM - please apply if no regressions and backport onto GCC 6 after the auto-testers have let this bake on trunk for a little while.
I'd rather not apply it to the release branches unless we can trigger it there but it maybe newer logic in the bswap pass that detects this.
regards
Ramana