[PATCH][ARM] PR target/71270 fix neon_valid_immediate for big-endian

[Kyrill Tkachov]

Ping.
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00381.html

Thanks,
Kyrill

On 06/01/17 11:54, Kyrill Tkachov wrote:
> Hi all,
>
> In this wrong-code issue the RTL tries to load a const_vector:
> (const_vector:V8QI [
>         (const_int 1 [0x1])
>         (const_int 0 [0])
>         (const_int 1 [0x1])
>         (const_int 0 [0])
>         (const_int 1 [0x1])
>         (const_int 0 [0])
>         (const_int 1 [0x1])
>         (const_int 0 [0])
>     ])
>
> into a NEON register. The logic for that is in neon_valid_immediate which does a number of tricks
> to decide what value and of what size to do a VMOV on to load the correct vector immediate into the register.
> It goes wrong on big-endian. On both big and little-endian this outputs:
> vmov.i16    d18, #0x1
>
> This is wrong on big-endian. The vector layout has to be such as if loaded from memory.
> I've tried various approaches of fixing neon_valid_immediate to generate the correct immediate but have been unsuccessful,
> resulting in regressions in various parts of the testsuite or making a big mess of the function.
>
> Given that armeb is not a target of major concern I believe the safest route at this stage is to only allow vector constants
> that will obviously work on big-endian, that is the ones that are just a single element duplicated in all lanes.
>
> This patch fixes the execution failures:
> FAIL: gfortran.dg/intrinsic_pack_1.f90
> FAIL: gfortran.dg/c_f_pointer_logical.f03
> FAIL: gcc.dg/torture/pr60183.c
> FAIL: gcc.dg/vect/pr51581-4.c
>
> on armeb-none-eabi.
>
> Ok for trunk?
>
> Thanks,
> Kyrill
>
> 2017-01-06  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>
>
>     PR target/71270
>     * config/arm/arm.c (neon_valid_immediate): Reject vector constants
>     in big-endian mode when they are not a single duplicated value.