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.tkac...@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.
