On 20 March 2018 at 18:11, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> wrote:
> Hi all,
>
> This PR shows that we get the load/store_lanes logic wrong for arm
> big-endian.
> It is tricky to get right. Aarch64 does it by adding the appropriate
> lane-swapping
> operations during expansion.
>
> I'd like to do the same on arm eventually, but we'd need to port and
> validate the VTBL-generating
> code and add it to all the right places and I'm not comfortable enough doing
> it for GCC 8, but I am keen
> in getting the wrong-code fixed.
> As I say in the PR, vectorisation on armeb is already severely restricted
> (we disable many patterns on BYTES_BIG_ENDIAN)
> and the load/store_lanes patterns really were not working properly at all,
> so disabling them is not
> a radical approach.
>
> The way to do that is to return false in ARRAY_MODE_SUPPORTED_P for
> BYTES_BIG_ENDIAN.
>
> Bootstrapped and tested on arm-none-linux-gnueabihf.
> Also tested on armeb-none-eabi.
>
> Committing to trunk.
> Thanks,
> Kyrill
>
> 2018-03-20 Kyrylo Tkachov <kyrylo.tkac...@arm.com>
>
> PR target/82518
> * config/arm/arm.c (arm_array_mode_supported_p): Return false for
> BYTES_BIG_ENDIAN.
>
> 2018-03-20 Kyrylo Tkachov <kyrylo.tkac...@arm.com>
>
> PR target/82518
> * lib/target-supports.exp (check_effective_target_vect_load_lanes):
> Disable for armeb targets.
> * gcc.target/arm/pr82518.c: New test.
Hi Kyrill,
I think you need:
Index: pr82518.c
===================================================================
--- pr82518.c (revision 258705)
+++ pr82518.c (working copy)
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-require-effective-target arm_neon_ok } */
+/* { dg-require-effective-target arm_neon_hw } */
/* { dg-additional-options "-O3 -fno-inline -std=gnu99" } */
/* { dg-add-options arm_neon } */
(The test fails to run for me when using qemu --cpu arm926)
OK?
Christophe
