[Bug target/82518] [6/7/8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb

2018-03-20 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518

--- Comment #52 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Mar 20 17:13:16 2018
New Revision: 258687

URL: https://gcc.gnu.org/viewcvs?rev=258687&root=gcc&view=rev
Log:
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.


 PR target/82518
 * config/arm/arm.c (arm_array_mode_supported_p): Return false for
 BYTES_BIG_ENDIAN.

 * lib/target-supports.exp (check_effective_target_vect_load_lanes):
 Disable for armeb targets.
 * gcc.target/arm/pr82518.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr82518.c
Modified:
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/lib/target-supports.exp

[Bug target/82518] [6/7/8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb

2018-02-20 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #51 from ktkachov at gcc dot gnu.org ---
Testing a simple patch along the lines described in comment #50

[Bug target/82518] [6/7/8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb

2018-02-20 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #50 from ktkachov at gcc dot gnu.org ---
(In reply to Wilco from comment #49)
> AArch64 does this:
> 
> (define_expand "vec_store_lanesoi"
>   [(set (match_operand:OI 0 "aarch64_simd_struct_operand" "=Utv")
> (unspec:OI [(match_operand:OI 1 "register_operand" "w")
> (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
>UNSPEC_ST2))]
>   "TARGET_SIMD"
> {
>   if (BYTES_BIG_ENDIAN)
> {
>   rtx tmp = gen_reg_rtx (OImode);
>   rtx mask = aarch64_reverse_mask (mode, );
>   emit_insn (gen_aarch64_rev_reglistoi (tmp, operands[1], mask));
>   emit_insn (gen_aarch64_simd_st2 (operands[0], tmp));
> }
>   else
> emit_insn (gen_aarch64_simd_st2 (operands[0], operands[1]));
>   DONE;
> })
> 
> ARM seems to be missing the swap:
> 
> (define_expand "vec_store_lanesoi"
>   [(set (match_operand:OI 0 "neon_struct_operand")
> (unspec:OI [(match_operand:OI 1 "s_register_operand")
> (unspec:VQ2 [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
>UNSPEC_VST2))]
>   "TARGET_NEON")
> 
> So clearly looks like a backend issue.

Indeed, and arm is missing the equivalent logic, including the reverse_mask,
rev_reglist etc.

For GCC 8 and the branches the least invasive fix would be to return false for
BYTES_BIG_ENDIAN in arm_array_mode_supported_p. That will disable the use of
the vec_load, vec_store lanes on big-endian. vectorisation on arm NEON is
already severely restricted (look at all the patterns in neon.md gated on
!BYTES_BIG_ENDIAN) and the vec_load/store_lanes has never worked correctly on
that target as far as I can see, so switching it off properly is not a radical
change.

At some point we'll want to take a holistic approach for NEON big-endian and
fix up (and document!) the lane-ordering everywhere, but the priority at this
stage is to fix the wrong-code in a not-too-invasive way.

[Bug target/82518] [6/7/8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb

2018-02-16 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518

Wilco  changed:

   What|Removed |Added

   Priority|P1  |P2
  Component|tree-optimization   |target
Version|8.0 |6.4.1
Summary|[8 regression]  |[6/7/8 regression]
   |gfortran.fortran-torture/ex |gfortran.fortran-torture/ex
   |ecute/in-pack.f90 fails on  |ecute/in-pack.f90 fails on
   |armeb since r252917 |armeb
  Known to fail||6.4.1