New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[David Sherwood]

[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

Hi All,

I have successfully rebased this and tested in conjunction with a patch from
Alan Hayward ([AArch64] [BE] Fix vector load/stores to not use ld1/st1), who
should be submitting a new version shortly. Built and tested on:

aarch64-none-elf
aarch64_be-none-elf
x86_64-linux-gnu

Regards,
David Sherwood.

-----Original Message-----
From: David Sherwood [mailto:david.sherwood@arm.com] 
Sent: 28 October 2014 08:55
To: 'gcc-patches@gcc.gnu.org'
Subject: RE: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

Hi,

Sorry to bother you again. Could someone take a look at this change
please if they have time?

Thanks!
David.

-----Original Message-----
From: David Sherwood [mailto:david.sherwood@arm.com] 
Sent: 10 October 2014 15:48
To: gcc-patches@gcc.gnu.org
Subject: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

Hi,

I have a fix (originally written by Tejas Belagod) for the following bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810

Could someone take a look please?

Thanks!
David Sherwood.

ChangeLog:

    gcc/:
    2014-11-13  David Sherwood  <david.sherwood@arm.com>

        * config/aarch64/aarch64-protos.h (aarch64_simd_attr_length_rglist,
        aarch64_reverse_mask): New decls.
        * config/aarch64/iterators.md (UNSPEC_REV_REGLIST): New enum.
        * config/aarch64/iterators.md (insn_count): New mode_attr.
       * config/aarch64/aarch64-simd.md (vec_store_lanes(o/c/x)i,
        vec_load_lanes(o/c/x)i): Fixed to work for Big Endian. 
        * config/aarch64/aarch64-simd.md (aarch64_rev_reglist,
        aarch64_simd_(ld/st)(2/3/4)): Added.
        * config/aarch64/aarch64.c (aarch64_simd_attr_length_rglist,
        aarch64_reverse_mask): Added.

[-- Attachment #2: ccmc_v1_rebase.patch --]
[-- Type: application/octet-stream, Size: 9995 bytes --]

diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index 470b9eb..494a1ae 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -196,6 +196,8 @@ bool aarch64_modes_tieable_p (machine_mode mode1,
 bool aarch64_move_imm (HOST_WIDE_INT, machine_mode);
 bool aarch64_mov_operand_p (rtx, enum aarch64_symbol_context,
 			    machine_mode);
+int aarch64_simd_attr_length_rglist (enum machine_mode);
+rtx aarch64_reverse_mask (enum machine_mode);
 bool aarch64_offset_7bit_signed_scaled_p (machine_mode, HOST_WIDE_INT);
 char *aarch64_output_scalar_simd_mov_immediate (rtx, machine_mode);
 char *aarch64_output_simd_mov_immediate (rtx, machine_mode, unsigned);
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index ef196e4..d3aed80 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -4035,7 +4035,7 @@
 
 ;; Patterns for vector struct loads and stores.
 
-(define_insn "vec_load_lanesoi<mode>"
+(define_insn "aarch64_simd_ld2<mode>"
   [(set (match_operand:OI 0 "register_operand" "=w")
 	(unspec:OI [(match_operand:OI 1 "aarch64_simd_struct_operand" "Utv")
 		    (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
@@ -4067,7 +4067,26 @@
   [(set_attr "type" "neon_load2_one_lane")]
 )
 
-(define_insn "vec_store_lanesoi<mode>"
+(define_expand "vec_load_lanesoi<mode>"
+  [(set (match_operand:OI 0 "register_operand" "=w")
+	(unspec:OI [(match_operand:OI 1 "aarch64_simd_struct_operand" "Utv")
+		    (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
+		   UNSPEC_LD2))]
+  "TARGET_SIMD"
+{
+  if (BYTES_BIG_ENDIAN)
+    {
+      rtx tmp = gen_reg_rtx (OImode);
+      rtx mask = aarch64_reverse_mask (<MODE>mode);
+      emit_insn (gen_aarch64_simd_ld2<mode> (tmp, operands[1]));
+      emit_insn (gen_aarch64_rev_reglistoi (operands[0], tmp, mask));
+    }
+  else
+    emit_insn (gen_aarch64_simd_ld2<mode> (operands[0], operands[1]));
+  DONE;
+})
+
+(define_insn "aarch64_simd_st2<mode>"
   [(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)]
@@ -4088,7 +4107,26 @@
   [(set_attr "type" "neon_store3_one_lane<q>")]
 )
 
-(define_insn "vec_load_lanesci<mode>"
+(define_expand "vec_store_lanesoi<mode>"
+  [(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>mode);
+      emit_insn (gen_aarch64_rev_reglistoi (tmp, operands[1], mask));
+      emit_insn (gen_aarch64_simd_st2<mode> (operands[0], tmp));
+    }
+  else
+    emit_insn (gen_aarch64_simd_st2<mode> (operands[0], operands[1]));
+  DONE;
+})
+
+(define_insn "aarch64_simd_ld3<mode>"
   [(set (match_operand:CI 0 "register_operand" "=w")
 	(unspec:CI [(match_operand:CI 1 "aarch64_simd_struct_operand" "Utv")
 		    (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
@@ -4120,7 +4158,26 @@
   [(set_attr "type" "neon_load3_one_lane")]
 )
 
-(define_insn "vec_store_lanesci<mode>"
+(define_expand "vec_load_lanesci<mode>"
+  [(set (match_operand:CI 0 "register_operand" "=w")
+	(unspec:CI [(match_operand:CI 1 "aarch64_simd_struct_operand" "Utv")
+		    (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
+		   UNSPEC_LD3))]
+  "TARGET_SIMD"
+{
+  if (BYTES_BIG_ENDIAN)
+    {
+      rtx tmp = gen_reg_rtx (CImode);
+      rtx mask = aarch64_reverse_mask (<MODE>mode);
+      emit_insn (gen_aarch64_simd_ld3<mode> (tmp, operands[1]));
+      emit_insn (gen_aarch64_rev_reglistci (operands[0], tmp, mask));
+    }
+  else
+    emit_insn (gen_aarch64_simd_ld3<mode> (operands[0], operands[1]));
+  DONE;
+})
+
+(define_insn "aarch64_simd_st3<mode>"
   [(set (match_operand:CI 0 "aarch64_simd_struct_operand" "=Utv")
 	(unspec:CI [(match_operand:CI 1 "register_operand" "w")
                     (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
@@ -4141,7 +4198,26 @@
   [(set_attr "type" "neon_store3_one_lane<q>")]
 )
 
-(define_insn "vec_load_lanesxi<mode>"
+(define_expand "vec_store_lanesci<mode>"
+  [(set (match_operand:CI 0 "aarch64_simd_struct_operand" "=Utv")
+	(unspec:CI [(match_operand:CI 1 "register_operand" "w")
+                    (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
+                   UNSPEC_ST3))]
+  "TARGET_SIMD"
+{
+  if (BYTES_BIG_ENDIAN)
+    {
+      rtx tmp = gen_reg_rtx (CImode);
+      rtx mask = aarch64_reverse_mask (<MODE>mode);
+      emit_insn (gen_aarch64_rev_reglistci (tmp, operands[1], mask));
+      emit_insn (gen_aarch64_simd_st3<mode> (operands[0], tmp));
+    }
+  else
+    emit_insn (gen_aarch64_simd_st3<mode> (operands[0], operands[1]));
+  DONE;
+})
+
+(define_insn "aarch64_simd_ld4<mode>"
   [(set (match_operand:XI 0 "register_operand" "=w")
 	(unspec:XI [(match_operand:XI 1 "aarch64_simd_struct_operand" "Utv")
 		    (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
@@ -4173,7 +4249,26 @@
   [(set_attr "type" "neon_load4_one_lane")]
 )
 
-(define_insn "vec_store_lanesxi<mode>"
+(define_expand "vec_load_lanesxi<mode>"
+  [(set (match_operand:XI 0 "register_operand" "=w")
+	(unspec:XI [(match_operand:XI 1 "aarch64_simd_struct_operand" "Utv")
+		    (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
+		   UNSPEC_LD4))]
+  "TARGET_SIMD"
+{
+  if (BYTES_BIG_ENDIAN)
+    {
+      rtx tmp = gen_reg_rtx (XImode);
+      rtx mask = aarch64_reverse_mask (<MODE>mode);
+      emit_insn (gen_aarch64_simd_ld4<mode> (tmp, operands[1]));
+      emit_insn (gen_aarch64_rev_reglistxi (operands[0], tmp, mask));
+    }
+  else
+    emit_insn (gen_aarch64_simd_ld4<mode> (operands[0], operands[1]));
+  DONE;
+})
+
+(define_insn "aarch64_simd_st4<mode>"
   [(set (match_operand:XI 0 "aarch64_simd_struct_operand" "=Utv")
 	(unspec:XI [(match_operand:XI 1 "register_operand" "w")
                     (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
@@ -4194,6 +4289,50 @@
   [(set_attr "type" "neon_store4_one_lane<q>")]
 )
 
+(define_expand "vec_store_lanesxi<mode>"
+  [(set (match_operand:XI 0 "aarch64_simd_struct_operand" "=Utv")
+	(unspec:XI [(match_operand:XI 1 "register_operand" "w")
+                    (unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
+                   UNSPEC_ST4))]
+  "TARGET_SIMD"
+{
+  if (BYTES_BIG_ENDIAN)
+    {
+      rtx tmp = gen_reg_rtx (XImode);
+      rtx mask = aarch64_reverse_mask (<MODE>mode);
+      emit_insn (gen_aarch64_rev_reglistxi (tmp, operands[1], mask));
+      emit_insn (gen_aarch64_simd_st4<mode> (operands[0], tmp));
+    }
+  else
+    emit_insn (gen_aarch64_simd_st4<mode> (operands[0], operands[1]));
+  DONE;
+})
+
+(define_insn_and_split "aarch64_rev_reglist<mode>"
+[(set (match_operand:VSTRUCT 0 "register_operand" "=&w")
+	(unspec:VSTRUCT
+	           [(match_operand:VSTRUCT 1 "register_operand" "w")
+		    (match_operand:V16QI 2 "register_operand" "w")]
+                   UNSPEC_REV_REGLIST))]
+  "TARGET_SIMD"
+  "#"
+  "&& reload_completed"
+  [(const_int 0)]
+{
+  int i;
+  int nregs = GET_MODE_SIZE (<MODE>mode) / UNITS_PER_VREG;
+  for (i = 0; i < nregs; i++)
+    {
+      rtx op0 = gen_rtx_REG (V16QImode, REGNO (operands[0]) + i);
+      rtx op1 = gen_rtx_REG (V16QImode, REGNO (operands[1]) + i);
+      emit_insn (gen_aarch64_tbl1v16qi (op0, op1, operands[2]));
+    }
+  DONE;
+}
+  [(set_attr "type" "neon_tbl1_q")
+   (set_attr "length" "<insn_count>")]
+)
+
 ;; Reload patterns for AdvSIMD register list operands.
 
 (define_expand "mov<mode>"
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 0429d96..dde9690 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -8239,6 +8239,14 @@ aarch64_simd_attr_length_move (rtx_insn *insn)
   return 4;
 }
 
+/* Compute and return the length of aarch64_simd_reglist<mode>, where <mode> is
+   one of VSTRUCT modes: OI, CI, EI, or XI.  */
+int
+aarch64_simd_attr_length_rglist (enum machine_mode mode)
+{
+  return (GET_MODE_SIZE (mode) / UNITS_PER_VREG) * 4;
+}
+
 /* Implement target hook TARGET_VECTOR_ALIGNMENT.  The AAPCS64 sets the maximum
    alignment of a vector to 128 bits.  */
 static HOST_WIDE_INT
@@ -9767,6 +9775,27 @@ aarch64_cannot_change_mode_class (machine_mode from,
   return true;
 }
 
+rtx
+aarch64_reverse_mask (enum machine_mode mode)
+{
+  /* We have to reverse each vector because we dont have
+     a permuted load that can reverse-load according to ABI rules.  */
+  rtx mask;
+  rtvec v = rtvec_alloc (16);
+  int i, j;
+  int nunits = GET_MODE_NUNITS (mode);
+  int usize = GET_MODE_UNIT_SIZE (mode);
+
+  gcc_assert (BYTES_BIG_ENDIAN);
+  gcc_assert (AARCH64_VALID_SIMD_QREG_MODE (mode));
+
+  for (i = 0; i < nunits; i++)
+    for (j = 0; j < usize; j++)
+      RTVEC_ELT (v, i * usize + j) = GEN_INT ((i + 1) * usize - 1 - j);
+  mask = gen_rtx_CONST_VECTOR (V16QImode, v);
+  return force_reg (V16QImode, mask);
+}
+
 /* Implement MODES_TIEABLE_P.  */
 
 bool
diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md
index 9935167..1772157 100644
--- a/gcc/config/aarch64/iterators.md
+++ b/gcc/config/aarch64/iterators.md
@@ -298,6 +298,7 @@
     UNSPEC_SHA256SU1    ; Used in aarch64-simd.md.
     UNSPEC_PMULL        ; Used in aarch64-simd.md.
     UNSPEC_PMULL2       ; Used in aarch64-simd.md.
+    UNSPEC_REV_REGLIST  ; Used in aarch64-simd.md.
 ])
 
 ;; -------------------------------------------------------------------
@@ -670,6 +671,8 @@
 		      (V2DI  "p") (V2DF  "p")
 		      (V2SF "p") (V4SF  "v")])
 
+(define_mode_attr insn_count [(OI "8") (CI "12") (XI "16")])
+
 ;; -------------------------------------------------------------------
 ;; Code Iterators
 ;; -------------------------------------------------------------------

Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[Christophe Lyon]

On 13 November 2014 11:09, David Sherwood <david.sherwood@arm.com> wrote:
> Hi All,
>
> I have successfully rebased this and tested in conjunction with a patch from
> Alan Hayward ([AArch64] [BE] Fix vector load/stores to not use ld1/st1), who
> should be submitting a new version shortly. Built and tested on:
>
> aarch64-none-elf
> aarch64_be-none-elf
> x86_64-linux-gnu

I've applied both patches to recent trunk (r217483), and I still see
ICEs on aarch64_be, when running the advsimd-intrinsics/vldX.c tests.

I have them with Alan Hayward's patch alone, too. BTW, I thought that
patch had been approved by Marcus, but it's not in trunk yet. Maybe I
missed something.

Christophe.

>
> Regards,
> David Sherwood.
>
> -----Original Message-----
> From: David Sherwood [mailto:david.sherwood@arm.com]
> Sent: 28 October 2014 08:55
> To: 'gcc-patches@gcc.gnu.org'
> Subject: RE: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>
> Hi,
>
> Sorry to bother you again. Could someone take a look at this change
> please if they have time?
>
> Thanks!
> David.
>
> -----Original Message-----
> From: David Sherwood [mailto:david.sherwood@arm.com]
> Sent: 10 October 2014 15:48
> To: gcc-patches@gcc.gnu.org
> Subject: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>
> Hi,
>
> I have a fix (originally written by Tejas Belagod) for the following bug:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
>
> Could someone take a look please?
>
> Thanks!
> David Sherwood.
>
> ChangeLog:
>
>     gcc/:
>     2014-11-13  David Sherwood  <david.sherwood@arm.com>
>
>         * config/aarch64/aarch64-protos.h (aarch64_simd_attr_length_rglist,
>         aarch64_reverse_mask): New decls.
>         * config/aarch64/iterators.md (UNSPEC_REV_REGLIST): New enum.
>         * config/aarch64/iterators.md (insn_count): New mode_attr.
>        * config/aarch64/aarch64-simd.md (vec_store_lanes(o/c/x)i,
>         vec_load_lanes(o/c/x)i): Fixed to work for Big Endian.
>         * config/aarch64/aarch64-simd.md (aarch64_rev_reglist,
>         aarch64_simd_(ld/st)(2/3/4)): Added.
>         * config/aarch64/aarch64.c (aarch64_simd_attr_length_rglist,
>         aarch64_reverse_mask): Added.

RE: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[David Sherwood]

Hi,

I think that's because Alan Hayward's original patch had a bug in it, which he
has fixed and should be submitting to gcc patches fairly soon. So it's probably
best waiting until he gets a new patch up I think.

Regards,
David.

-----Original Message-----
From: Christophe Lyon [mailto:christophe.lyon@linaro.org] 
Sent: 13 November 2014 14:22
To: David Sherwood
Cc: gcc-patches@gcc.gnu.org
Subject: Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

On 13 November 2014 11:09, David Sherwood <david.sherwood@arm.com> wrote:
> Hi All,
>
> I have successfully rebased this and tested in conjunction with a patch from
> Alan Hayward ([AArch64] [BE] Fix vector load/stores to not use ld1/st1), who
> should be submitting a new version shortly. Built and tested on:
>
> aarch64-none-elf
> aarch64_be-none-elf
> x86_64-linux-gnu

I've applied both patches to recent trunk (r217483), and I still see
ICEs on aarch64_be, when running the advsimd-intrinsics/vldX.c tests.

I have them with Alan Hayward's patch alone, too. BTW, I thought that
patch had been approved by Marcus, but it's not in trunk yet. Maybe I
missed something.

Christophe.

>
> Regards,
> David Sherwood.
>
> -----Original Message-----
> From: David Sherwood [mailto:david.sherwood@arm.com]
> Sent: 28 October 2014 08:55
> To: 'gcc-patches@gcc.gnu.org'
> Subject: RE: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>
> Hi,
>
> Sorry to bother you again. Could someone take a look at this change
> please if they have time?
>
> Thanks!
> David.
>
> -----Original Message-----
> From: David Sherwood [mailto:david.sherwood@arm.com]
> Sent: 10 October 2014 15:48
> To: gcc-patches@gcc.gnu.org
> Subject: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>
> Hi,
>
> I have a fix (originally written by Tejas Belagod) for the following bug:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
>
> Could someone take a look please?
>
> Thanks!
> David Sherwood.
>
> ChangeLog:
>
>     gcc/:
>     2014-11-13  David Sherwood  <david.sherwood@arm.com>
>
>         * config/aarch64/aarch64-protos.h (aarch64_simd_attr_length_rglist,
>         aarch64_reverse_mask): New decls.
>         * config/aarch64/iterators.md (UNSPEC_REV_REGLIST): New enum.
>         * config/aarch64/iterators.md (insn_count): New mode_attr.
>        * config/aarch64/aarch64-simd.md (vec_store_lanes(o/c/x)i,
>         vec_load_lanes(o/c/x)i): Fixed to work for Big Endian.
>         * config/aarch64/aarch64-simd.md (aarch64_rev_reglist,
>         aarch64_simd_(ld/st)(2/3/4)): Added.
>         * config/aarch64/aarch64.c (aarch64_simd_attr_length_rglist,
>         aarch64_reverse_mask): Added.

Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[Christophe Lyon]

On 13 November 2014 15:32, David Sherwood <david.sherwood@arm.com> wrote:
> Hi,
>
> I think that's because Alan Hayward's original patch had a bug in it, which he
> has fixed and should be submitting to gcc patches fairly soon. So it's probably
> best waiting until he gets a new patch up I think.
>

I've applied both Alan's patches and the advsimd-intrinsics tests now
all pass on aarch64_be, but this doesn't need your patch.

Which testcase does your patch actually fix?


> Regards,
> David.
>
> -----Original Message-----
> From: Christophe Lyon [mailto:christophe.lyon@linaro.org]
> Sent: 13 November 2014 14:22
> To: David Sherwood
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>
> On 13 November 2014 11:09, David Sherwood <david.sherwood@arm.com> wrote:
>> Hi All,
>>
>> I have successfully rebased this and tested in conjunction with a patch from
>> Alan Hayward ([AArch64] [BE] Fix vector load/stores to not use ld1/st1), who
>> should be submitting a new version shortly. Built and tested on:
>>
>> aarch64-none-elf
>> aarch64_be-none-elf
>> x86_64-linux-gnu
>
> I've applied both patches to recent trunk (r217483), and I still see
> ICEs on aarch64_be, when running the advsimd-intrinsics/vldX.c tests.
>
> I have them with Alan Hayward's patch alone, too. BTW, I thought that
> patch had been approved by Marcus, but it's not in trunk yet. Maybe I
> missed something.
>
> Christophe.
>
>>
>> Regards,
>> David Sherwood.
>>
>> -----Original Message-----
>> From: David Sherwood [mailto:david.sherwood@arm.com]
>> Sent: 28 October 2014 08:55
>> To: 'gcc-patches@gcc.gnu.org'
>> Subject: RE: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>>
>> Hi,
>>
>> Sorry to bother you again. Could someone take a look at this change
>> please if they have time?
>>
>> Thanks!
>> David.
>>
>> -----Original Message-----
>> From: David Sherwood [mailto:david.sherwood@arm.com]
>> Sent: 10 October 2014 15:48
>> To: gcc-patches@gcc.gnu.org
>> Subject: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>>
>> Hi,
>>
>> I have a fix (originally written by Tejas Belagod) for the following bug:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
>>
>> Could someone take a look please?
>>
>> Thanks!
>> David Sherwood.
>>
>> ChangeLog:
>>
>>     gcc/:
>>     2014-11-13  David Sherwood  <david.sherwood@arm.com>
>>
>>         * config/aarch64/aarch64-protos.h (aarch64_simd_attr_length_rglist,
>>         aarch64_reverse_mask): New decls.
>>         * config/aarch64/iterators.md (UNSPEC_REV_REGLIST): New enum.
>>         * config/aarch64/iterators.md (insn_count): New mode_attr.
>>        * config/aarch64/aarch64-simd.md (vec_store_lanes(o/c/x)i,
>>         vec_load_lanes(o/c/x)i): Fixed to work for Big Endian.
>>         * config/aarch64/aarch64-simd.md (aarch64_rev_reglist,
>>         aarch64_simd_(ld/st)(2/3/4)): Added.
>>         * config/aarch64/aarch64.c (aarch64_simd_attr_length_rglist,
>>         aarch64_reverse_mask): Added.
>
>
>
>

RE: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[David Sherwood]

Hi Christophe,

Ah sorry. My mistake - it fixes this in bugzilla:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810

This change is needed in order to remove the CANNOT_CHANGE_MODE_CLASS
#define, which will be committed as a separate patch.

Regards,
David Sherwood.

-----Original Message-----
From: Christophe Lyon [mailto:christophe.lyon@linaro.org] 
Sent: 17 November 2014 21:09
To: David Sherwood
Cc: gcc-patches@gcc.gnu.org; Alan Hayward
Subject: Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

On 13 November 2014 15:32, David Sherwood <david.sherwood@arm.com> wrote:
> Hi,
>
> I think that's because Alan Hayward's original patch had a bug in it, which he
> has fixed and should be submitting to gcc patches fairly soon. So it's probably
> best waiting until he gets a new patch up I think.
>

I've applied both Alan's patches and the advsimd-intrinsics tests now
all pass on aarch64_be, but this doesn't need your patch.

Which testcase does your patch actually fix?


> Regards,
> David.
>
> -----Original Message-----
> From: Christophe Lyon [mailto:christophe.lyon@linaro.org]
> Sent: 13 November 2014 14:22
> To: David Sherwood
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>
> On 13 November 2014 11:09, David Sherwood <david.sherwood@arm.com> wrote:
>> Hi All,
>>
>> I have successfully rebased this and tested in conjunction with a patch from
>> Alan Hayward ([AArch64] [BE] Fix vector load/stores to not use ld1/st1), who
>> should be submitting a new version shortly. Built and tested on:
>>
>> aarch64-none-elf
>> aarch64_be-none-elf
>> x86_64-linux-gnu
>
> I've applied both patches to recent trunk (r217483), and I still see
> ICEs on aarch64_be, when running the advsimd-intrinsics/vldX.c tests.
>
> I have them with Alan Hayward's patch alone, too. BTW, I thought that
> patch had been approved by Marcus, but it's not in trunk yet. Maybe I
> missed something.
>
> Christophe.
>
>>
>> Regards,
>> David Sherwood.
>>
>> -----Original Message-----
>> From: David Sherwood [mailto:david.sherwood@arm.com]
>> Sent: 28 October 2014 08:55
>> To: 'gcc-patches@gcc.gnu.org'
>> Subject: RE: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>>
>> Hi,
>>
>> Sorry to bother you again. Could someone take a look at this change
>> please if they have time?
>>
>> Thanks!
>> David.
>>
>> -----Original Message-----
>> From: David Sherwood [mailto:david.sherwood@arm.com]
>> Sent: 10 October 2014 15:48
>> To: gcc-patches@gcc.gnu.org
>> Subject: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>>
>> Hi,
>>
>> I have a fix (originally written by Tejas Belagod) for the following bug:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
>>
>> Could someone take a look please?
>>
>> Thanks!
>> David Sherwood.
>>
>> ChangeLog:
>>
>>     gcc/:
>>     2014-11-13  David Sherwood  <david.sherwood@arm.com>
>>
>>         * config/aarch64/aarch64-protos.h (aarch64_simd_attr_length_rglist,
>>         aarch64_reverse_mask): New decls.
>>         * config/aarch64/iterators.md (UNSPEC_REV_REGLIST): New enum.
>>         * config/aarch64/iterators.md (insn_count): New mode_attr.
>>        * config/aarch64/aarch64-simd.md (vec_store_lanes(o/c/x)i,
>>         vec_load_lanes(o/c/x)i): Fixed to work for Big Endian.
>>         * config/aarch64/aarch64-simd.md (aarch64_rev_reglist,
>>         aarch64_simd_(ld/st)(2/3/4)): Added.
>>         * config/aarch64/aarch64.c (aarch64_simd_attr_length_rglist,
>>         aarch64_reverse_mask): Added.
>
>
>
>

Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[Christophe Lyon]

On 18 November 2014 10:14, David Sherwood <david.sherwood@arm.com> wrote:
> Hi Christophe,
>
> Ah sorry. My mistake - it fixes this in bugzilla:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810

I did look at that PR, but since it has no testcase attached, I was unsure.
And I am still not :-)
PR 59810 is "[AArch64] LDn/STn implementations are not ABI-conformant
for bigendian."
but the advsimd-intrinsics/vldX.c and vldX_lane.c now PASS with Alan's
patches on aarch64_be, so I thought Alan's patches solve PR59810.

What am I missing?



>
> This change is needed in order to remove the CANNOT_CHANGE_MODE_CLASS
> #define, which will be committed as a separate patch.
>
> Regards,
> David Sherwood.
>
> -----Original Message-----
> From: Christophe Lyon [mailto:christophe.lyon@linaro.org]
> Sent: 17 November 2014 21:09
> To: David Sherwood
> Cc: gcc-patches@gcc.gnu.org; Alan Hayward
> Subject: Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>
> On 13 November 2014 15:32, David Sherwood <david.sherwood@arm.com> wrote:
>> Hi,
>>
>> I think that's because Alan Hayward's original patch had a bug in it, which he
>> has fixed and should be submitting to gcc patches fairly soon. So it's probably
>> best waiting until he gets a new patch up I think.
>>
>
> I've applied both Alan's patches and the advsimd-intrinsics tests now
> all pass on aarch64_be, but this doesn't need your patch.
>
> Which testcase does your patch actually fix?
>
>
>> Regards,
>> David.
>>
>> -----Original Message-----
>> From: Christophe Lyon [mailto:christophe.lyon@linaro.org]
>> Sent: 13 November 2014 14:22
>> To: David Sherwood
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>>
>> On 13 November 2014 11:09, David Sherwood <david.sherwood@arm.com> wrote:
>>> Hi All,
>>>
>>> I have successfully rebased this and tested in conjunction with a patch from
>>> Alan Hayward ([AArch64] [BE] Fix vector load/stores to not use ld1/st1), who
>>> should be submitting a new version shortly. Built and tested on:
>>>
>>> aarch64-none-elf
>>> aarch64_be-none-elf
>>> x86_64-linux-gnu
>>
>> I've applied both patches to recent trunk (r217483), and I still see
>> ICEs on aarch64_be, when running the advsimd-intrinsics/vldX.c tests.
>>
>> I have them with Alan Hayward's patch alone, too. BTW, I thought that
>> patch had been approved by Marcus, but it's not in trunk yet. Maybe I
>> missed something.
>>
>> Christophe.
>>
>>>
>>> Regards,
>>> David Sherwood.
>>>
>>> -----Original Message-----
>>> From: David Sherwood [mailto:david.sherwood@arm.com]
>>> Sent: 28 October 2014 08:55
>>> To: 'gcc-patches@gcc.gnu.org'
>>> Subject: RE: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>>>
>>> Hi,
>>>
>>> Sorry to bother you again. Could someone take a look at this change
>>> please if they have time?
>>>
>>> Thanks!
>>> David.
>>>
>>> -----Original Message-----
>>> From: David Sherwood [mailto:david.sherwood@arm.com]
>>> Sent: 10 October 2014 15:48
>>> To: gcc-patches@gcc.gnu.org
>>> Subject: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>>>
>>> Hi,
>>>
>>> I have a fix (originally written by Tejas Belagod) for the following bug:
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
>>>
>>> Could someone take a look please?
>>>
>>> Thanks!
>>> David Sherwood.
>>>
>>> ChangeLog:
>>>
>>>     gcc/:
>>>     2014-11-13  David Sherwood  <david.sherwood@arm.com>
>>>
>>>         * config/aarch64/aarch64-protos.h (aarch64_simd_attr_length_rglist,
>>>         aarch64_reverse_mask): New decls.
>>>         * config/aarch64/iterators.md (UNSPEC_REV_REGLIST): New enum.
>>>         * config/aarch64/iterators.md (insn_count): New mode_attr.
>>>        * config/aarch64/aarch64-simd.md (vec_store_lanes(o/c/x)i,
>>>         vec_load_lanes(o/c/x)i): Fixed to work for Big Endian.
>>>         * config/aarch64/aarch64-simd.md (aarch64_rev_reglist,
>>>         aarch64_simd_(ld/st)(2/3/4)): Added.
>>>         * config/aarch64/aarch64.c (aarch64_simd_attr_length_rglist,
>>>         aarch64_reverse_mask): Added.
>>
>>
>>
>>
>
>
>
>

Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[Marcus Shawcroft]

On 13 November 2014 10:09, David Sherwood <david.sherwood@arm.com> wrote:

>     gcc/:
>     2014-11-13  David Sherwood  <david.sherwood@arm.com>
>
>         * config/aarch64/aarch64-protos.h (aarch64_simd_attr_length_rglist,
>         aarch64_reverse_mask): New decls.
>         * config/aarch64/iterators.md (UNSPEC_REV_REGLIST): New enum.
>         * config/aarch64/iterators.md (insn_count): New mode_attr.
>        * config/aarch64/aarch64-simd.md (vec_store_lanes(o/c/x)i,
>         vec_load_lanes(o/c/x)i): Fixed to work for Big Endian.

Spell these out in full please, some folks like to be able to grep for
function names in these logs.

>         * config/aarch64/aarch64-simd.md (aarch64_rev_reglist,
>         aarch64_simd_(ld/st)(2/3/4)): Added.

Likewise.

>         * config/aarch64/aarch64.c (aarch64_simd_attr_length_rglist,
>         aarch64_reverse_mask): Added.

It isn;t clear to me how far through the various BE patches we need to
get before 59810 is actually resolved?

Cheers
/Marcus

RE: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[David Sherwood]

> On 18 November 2014 10:14, David Sherwood <david.sherwood@arm.com> wrote:
> > Hi Christophe,
> >
> > Ah sorry. My mistake - it fixes this in bugzilla:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
> 
> I did look at that PR, but since it has no testcase attached, I was unsure.
> And I am still not :-)
> PR 59810 is "[AArch64] LDn/STn implementations are not ABI-conformant
> for bigendian."
> but the advsimd-intrinsics/vldX.c and vldX_lane.c now PASS with Alan's
> patches on aarch64_be, so I thought Alan's patches solve PR59810.
> 
> What am I missing?

Hi Christophe,

I think probably this is our fault for making our lives way too difficult and
artificially splitting all these patches up. :)

Alan's patch:

https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00952.html

fixes some issues on aarch64_be, but also causes regressions. For example,

====
Tests that now fail, but worked before:

aarch64_be-elf-aem: gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects execution test
aarch64_be-elf-aem: gcc.dg/vect/slp-perm-8.c execution test
aarch64_be-elf-aem: gcc.dg/vect/vect-over-widen-1-big-array.c -flto -ffat-lto-objects execution test
...

Tests that now work, but didn't before:

aarch64_be-elf-aem: gcc.dg/vect/fast-math-vect-complex-3.c execution test
aarch64_be-elf-aem: gcc.dg/vect/if-cvt-stores-vect-ifcvt-18.c execution test
aarch64_be-elf-aem: gcc.dg/vect/no-scevccp-outer-10a.c execution test
...
====

His patch is only half of the story and must be applied at the same time as the
"[AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe."
patch. With both patches applied the result looks much healthier:

====
# Comparing 1 common sum files
## /bin/sh ./src/gcc/contrib/compare_tests  /tmp/gxx-sum1.10051 /tmp/gxx-sum2.10051
Tests that now work, but didn't before:

aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer  execution test
aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  execution test
aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer -funroll-loops  execution test
...
====

with no new regressions. After applying both patches the aarch64_be gcc testsuite is
on a parity with the aarch64 testsuite. Furthermore, after applying both of these patches:

"[AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe"
"[AArch64] [BE] Fix vector load/stores to not use ld1/st1"

it then becomes safe for us to remove the CCMC macro, which is the cause of 
unnecessary spills to the stack for certain auto-vectorised code. So really I
suppose when I posted my second patch

"[AArch64] [BE] [2/2] Make large opaque integer modes endianness-safe"

I should have really just called this

"[AArch64] [BE] Remove CCMC for aarch64"

in order to make it clear exactly what the purpose of these patches is.

Kind Regards,
David Sherwood.

RE: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[David Sherwood]

Hi Christophe,

Sorry to bother you again. After my clarification email below are you now
happy for these patches to go in?

Kind Regards,
David Sherwood.

> -----Original Message-----
> From: David Sherwood [mailto:david.sherwood@arm.com]
> Sent: 27 November 2014 14:53
> To: 'Christophe Lyon'
> Cc: gcc-patches@gcc.gnu.org; Marcus Shawcroft; Alan Hayward; 'Tejas Belagod'; Richard Sandiford
> Subject: RE: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
> 
> > On 18 November 2014 10:14, David Sherwood <david.sherwood@arm.com> wrote:
> > > Hi Christophe,
> > >
> > > Ah sorry. My mistake - it fixes this in bugzilla:
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
> >
> > I did look at that PR, but since it has no testcase attached, I was unsure.
> > And I am still not :-)
> > PR 59810 is "[AArch64] LDn/STn implementations are not ABI-conformant
> > for bigendian."
> > but the advsimd-intrinsics/vldX.c and vldX_lane.c now PASS with Alan's
> > patches on aarch64_be, so I thought Alan's patches solve PR59810.
> >
> > What am I missing?
> 
> Hi Christophe,
> 
> I think probably this is our fault for making our lives way too difficult and
> artificially splitting all these patches up. :)
> 
> Alan's patch:
> 
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00952.html
> 
> fixes some issues on aarch64_be, but also causes regressions. For example,
> 
> ====
> Tests that now fail, but worked before:
> 
> aarch64_be-elf-aem: gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects execution test
> aarch64_be-elf-aem: gcc.dg/vect/slp-perm-8.c execution test
> aarch64_be-elf-aem: gcc.dg/vect/vect-over-widen-1-big-array.c -flto -ffat-lto-objects execution test
> ...
> 
> Tests that now work, but didn't before:
> 
> aarch64_be-elf-aem: gcc.dg/vect/fast-math-vect-complex-3.c execution test
> aarch64_be-elf-aem: gcc.dg/vect/if-cvt-stores-vect-ifcvt-18.c execution test
> aarch64_be-elf-aem: gcc.dg/vect/no-scevccp-outer-10a.c execution test
> ...
> ====
> 
> His patch is only half of the story and must be applied at the same time as the
> "[AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe."
> patch. With both patches applied the result looks much healthier:
> 
> ====
> # Comparing 1 common sum files
> ## /bin/sh ./src/gcc/contrib/compare_tests  /tmp/gxx-sum1.10051 /tmp/gxx-sum2.10051
> Tests that now work, but didn't before:
> 
> aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer  execution test
> aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer -funroll-all-loops -finline-
> functions  execution test
> aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer -funroll-loops  execution test
> ...
> ====
> 
> with no new regressions. After applying both patches the aarch64_be gcc testsuite is
> on a parity with the aarch64 testsuite. Furthermore, after applying both of these patches:
> 
> "[AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe"
> "[AArch64] [BE] Fix vector load/stores to not use ld1/st1"
> 
> it then becomes safe for us to remove the CCMC macro, which is the cause of
> unnecessary spills to the stack for certain auto-vectorised code. So really I
> suppose when I posted my second patch
> 
> "[AArch64] [BE] [2/2] Make large opaque integer modes endianness-safe"
> 
> I should have really just called this
> 
> "[AArch64] [BE] Remove CCMC for aarch64"
> 
> in order to make it clear exactly what the purpose of these patches is.
> 
> Kind Regards,
> David Sherwood.

Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[Christophe Lyon]

On 11 December 2014 at 11:16, David Sherwood <david.sherwood@arm.com> wrote:
> Hi Christophe,
>
> Sorry to bother you again. After my clarification email below are you now
> happy for these patches to go in?
>
> Kind Regards,
> David Sherwood.
>
>> -----Original Message-----
>> From: David Sherwood [mailto:david.sherwood@arm.com]
>> Sent: 27 November 2014 14:53
>> To: 'Christophe Lyon'
>> Cc: gcc-patches@gcc.gnu.org; Marcus Shawcroft; Alan Hayward; 'Tejas Belagod'; Richard Sandiford
>> Subject: RE: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>>
>> > On 18 November 2014 10:14, David Sherwood <david.sherwood@arm.com> wrote:
>> > > Hi Christophe,
>> > >
>> > > Ah sorry. My mistake - it fixes this in bugzilla:
>> > >
>> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
>> >
>> > I did look at that PR, but since it has no testcase attached, I was unsure.
>> > And I am still not :-)
>> > PR 59810 is "[AArch64] LDn/STn implementations are not ABI-conformant
>> > for bigendian."
>> > but the advsimd-intrinsics/vldX.c and vldX_lane.c now PASS with Alan's
>> > patches on aarch64_be, so I thought Alan's patches solve PR59810.
>> >
>> > What am I missing?
>>
>> Hi Christophe,
>>
>> I think probably this is our fault for making our lives way too difficult and
>> artificially splitting all these patches up. :)
>>
>> Alan's patch:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00952.html
>>
>> fixes some issues on aarch64_be, but also causes regressions. For example,
>>
>> ====
>> Tests that now fail, but worked before:
>>
>> aarch64_be-elf-aem: gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects execution test
>> aarch64_be-elf-aem: gcc.dg/vect/slp-perm-8.c execution test
>> aarch64_be-elf-aem: gcc.dg/vect/vect-over-widen-1-big-array.c -flto -ffat-lto-objects execution test
>> ...
>>
>> Tests that now work, but didn't before:
>>
>> aarch64_be-elf-aem: gcc.dg/vect/fast-math-vect-complex-3.c execution test
>> aarch64_be-elf-aem: gcc.dg/vect/if-cvt-stores-vect-ifcvt-18.c execution test
>> aarch64_be-elf-aem: gcc.dg/vect/no-scevccp-outer-10a.c execution test
>> ...
>> ====
I didn't notice that because I tested Alan's patch only against the
advsimd-intrinsics tests.
In this respect, I don't understand why your ChangeLog entry says
       * config/aarch64/aarch64-simd.md (vec_store_lanes(o/c/x)i,
        vec_load_lanes(o/c/x)i): Fixed to work for Big Endian.
since the existing advsimd-intrinsics tests already pass with Alan's patch alone
or is vld1_lane still broken (for which I haven't posted a test yet)?

>> His patch is only half of the story and must be applied at the same time as the
>> "[AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe."
>> patch. With both patches applied the result looks much healthier:
>>
>> ====
>> # Comparing 1 common sum files
>> ## /bin/sh ./src/gcc/contrib/compare_tests  /tmp/gxx-sum1.10051 /tmp/gxx-sum2.10051
>> Tests that now work, but didn't before:
>>
>> aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer  execution test
>> aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer -funroll-all-loops -finline-
>> functions  execution test
>> aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer -funroll-loops  execution test
>> ...
>> ====
>>
>> with no new regressions. After applying both patches the aarch64_be gcc testsuite is
>> on a parity with the aarch64 testsuite. Furthermore, after applying both of these patches:
>>
>> "[AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe"
>> "[AArch64] [BE] Fix vector load/stores to not use ld1/st1"
>>
>> it then becomes safe for us to remove the CCMC macro, which is the cause of
>> unnecessary spills to the stack for certain auto-vectorised code. So really I
>> suppose when I posted my second patch
>>
>> "[AArch64] [BE] [2/2] Make large opaque integer modes endianness-safe"
>>
>> I should have really just called this
>>
>> "[AArch64] [BE] Remove CCMC for aarch64"
>>
>> in order to make it clear exactly what the purpose of these patches is.
well, not yet since this very does not remove it :-)

>>
>> Kind Regards,
>> David Sherwood.
>
>
>
>

RE: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[David Sherwood]

> -----Original Message-----
> From: Christophe Lyon [mailto:christophe.lyon@linaro.org]
> Sent: 11 December 2014 13:47
> To: David Sherwood
> Cc: gcc-patches@gcc.gnu.org; Marcus Shawcroft; Alan Hayward; Tejas Belagod; Richard Sandiford
> Subject: Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
> 
> On 11 December 2014 at 11:16, David Sherwood <david.sherwood@arm.com> wrote:
> > Hi Christophe,
> >
> > Sorry to bother you again. After my clarification email below are you now
> > happy for these patches to go in?
> >
> > Kind Regards,
> > David Sherwood.
> >
> >> -----Original Message-----
> >> From: David Sherwood [mailto:david.sherwood@arm.com]
> >> Sent: 27 November 2014 14:53
> >> To: 'Christophe Lyon'
> >> Cc: gcc-patches@gcc.gnu.org; Marcus Shawcroft; Alan Hayward; 'Tejas Belagod'; Richard Sandiford
> >> Subject: RE: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
> >>
> >> > On 18 November 2014 10:14, David Sherwood <david.sherwood@arm.com> wrote:
> >> > > Hi Christophe,
> >> > >
> >> > > Ah sorry. My mistake - it fixes this in bugzilla:
> >> > >
> >> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
> >> >
> >> > I did look at that PR, but since it has no testcase attached, I was unsure.
> >> > And I am still not :-)
> >> > PR 59810 is "[AArch64] LDn/STn implementations are not ABI-conformant
> >> > for bigendian."
> >> > but the advsimd-intrinsics/vldX.c and vldX_lane.c now PASS with Alan's
> >> > patches on aarch64_be, so I thought Alan's patches solve PR59810.
> >> >
> >> > What am I missing?
> >>
> >> Hi Christophe,
> >>
> >> I think probably this is our fault for making our lives way too difficult and
> >> artificially splitting all these patches up. :)
> >>
> >> Alan's patch:
> >>
> >> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00952.html
> >>
> >> fixes some issues on aarch64_be, but also causes regressions. For example,
> >>
> >> ====
> >> Tests that now fail, but worked before:
> >>
> >> aarch64_be-elf-aem: gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects execution test
> >> aarch64_be-elf-aem: gcc.dg/vect/slp-perm-8.c execution test
> >> aarch64_be-elf-aem: gcc.dg/vect/vect-over-widen-1-big-array.c -flto -ffat-lto-objects execution test
> >> ...
> >>
> >> Tests that now work, but didn't before:
> >>
> >> aarch64_be-elf-aem: gcc.dg/vect/fast-math-vect-complex-3.c execution test
> >> aarch64_be-elf-aem: gcc.dg/vect/if-cvt-stores-vect-ifcvt-18.c execution test
> >> aarch64_be-elf-aem: gcc.dg/vect/no-scevccp-outer-10a.c execution test
> >> ...
> >> ====
> I didn't notice that because I tested Alan's patch only against the
> advsimd-intrinsics tests.
> In this respect, I don't understand why your ChangeLog entry says
>        * config/aarch64/aarch64-simd.md (vec_store_lanes(o/c/x)i,
>         vec_load_lanes(o/c/x)i): Fixed to work for Big Endian.
> since the existing advsimd-intrinsics tests already pass with Alan's patch alone
> or is vld1_lane still broken (for which I haven't posted a test yet)?
> 
Yes, I think the change log is unclear and I will change it. The only thing that was
broken was not adhering to the ABI, but we don't have any specific regression tests
that prove this.

> >> His patch is only half of the story and must be applied at the same time as the
> >> "[AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe."
> >> patch. With both patches applied the result looks much healthier:
> >>
> >> ====
> >> # Comparing 1 common sum files
> >> ## /bin/sh ./src/gcc/contrib/compare_tests  /tmp/gxx-sum1.10051 /tmp/gxx-sum2.10051
> >> Tests that now work, but didn't before:
> >>
> >> aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer  execution test
> >> aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer -funroll-all-loops -finline-
> >> functions  execution test
> >> aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer -funroll-loops  execution
> test
> >> ...
> >> ====
> >>
> >> with no new regressions. After applying both patches the aarch64_be gcc testsuite is
> >> on a parity with the aarch64 testsuite. Furthermore, after applying both of these patches:
> >>
> >> "[AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe"
> >> "[AArch64] [BE] Fix vector load/stores to not use ld1/st1"
> >>
> >> it then becomes safe for us to remove the CCMC macro, which is the cause of
> >> unnecessary spills to the stack for certain auto-vectorised code. So really I
> >> suppose when I posted my second patch
> >>
> >> "[AArch64] [BE] [2/2] Make large opaque integer modes endianness-safe"
> >>
> >> I should have really just called this
> >>
> >> "[AArch64] [BE] Remove CCMC for aarch64"
> >>
> >> in order to make it clear exactly what the purpose of these patches is.
> well, not yet since this very does not remove it :-)
> 
Again, this is my fault as I made a mistake in the change log. If you look at the
actual patch the CCMC macro is removed. Let me re-post corrected, more
sensible change logs for both of those changes here:

"[AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe"
ChangeLog:

    gcc/:
    2014-10-10  David Sherwood  <david.sherwood@arm.com>
    2014-10-10  Tejas Belagod <Tejas.Belagod@arm.com>

        * config/aarch64/aarch64-protos.h (aarch64_simd_attr_length_rglist,
        aarch64_reverse_mask): New decls.
        * config/aarch64/iterators.md (UNSPEC_REV_REGLIST): New enum.
        * config/aarch64/iterators.md (insn_count): New mode_attr.
        * config/aarch64/aarch64-simd.md (vec_store_lanesoi, vec_store_lanesci,
        vec_store_lanesxi, vec_load_lanesoi, vec_load_lanesci, vec_load_lanesxi)
        : Made ABI compliant for Big Endian targets.
        * config/aarch64/aarch64-simd.md (aarch64_rev_reglist, aarch64_simd_ld2,
        aarch64_simd_ld3, aarch64_simd_ld4, aarch64_simd_st2, aarch64_simd_st3,
        aarch64_simd_st4): Added.
        * config/aarch64/aarch64.c (aarch64_simd_attr_length_rglist,
        aarch64_reverse_mask): Added.

"[AArch64] [BE] [2/2] Make large opaque integer modes endianness-safe"
ChangeLog:

    gcc/:
    2014-13-10  David Sherwood  <david.sherwood@arm.com>
    2014-13-10  Tejas Belagod <Tejas.Belagod@arm.com>

        * config/aarch64/aarch64.h (CANNOT_CHANGE_MODE_CLASS): Removed.
        * config/aarch64/aarch64.c (aarch64_cannot_change_mode_class): Removed.
        * config/aarch64/aarch64-protos.h (aarch64_cannot_change_mode_class):
        Removed.

Again, apologies for the confusion,
David.

> >>
> >> Kind Regards,
> >> David Sherwood.
> >
> >
> >
> >

Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[Christophe Lyon]

On 15 December 2014 at 10:56, David Sherwood <david.sherwood@arm.com> wrote:
>
>
>> -----Original Message-----
>> From: Christophe Lyon [mailto:christophe.lyon@linaro.org]
>> Sent: 11 December 2014 13:47
>> To: David Sherwood
>> Cc: gcc-patches@gcc.gnu.org; Marcus Shawcroft; Alan Hayward; Tejas Belagod; Richard Sandiford
>> Subject: Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>>
>> On 11 December 2014 at 11:16, David Sherwood <david.sherwood@arm.com> wrote:
>> > Hi Christophe,
>> >
>> > Sorry to bother you again. After my clarification email below are you now
>> > happy for these patches to go in?
>> >
>> > Kind Regards,
>> > David Sherwood.
>> >
>> >> -----Original Message-----
>> >> From: David Sherwood [mailto:david.sherwood@arm.com]
>> >> Sent: 27 November 2014 14:53
>> >> To: 'Christophe Lyon'
>> >> Cc: gcc-patches@gcc.gnu.org; Marcus Shawcroft; Alan Hayward; 'Tejas Belagod'; Richard Sandiford
>> >> Subject: RE: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.
>> >>
>> >> > On 18 November 2014 10:14, David Sherwood <david.sherwood@arm.com> wrote:
>> >> > > Hi Christophe,
>> >> > >
>> >> > > Ah sorry. My mistake - it fixes this in bugzilla:
>> >> > >
>> >> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
>> >> >
>> >> > I did look at that PR, but since it has no testcase attached, I was unsure.
>> >> > And I am still not :-)
>> >> > PR 59810 is "[AArch64] LDn/STn implementations are not ABI-conformant
>> >> > for bigendian."
>> >> > but the advsimd-intrinsics/vldX.c and vldX_lane.c now PASS with Alan's
>> >> > patches on aarch64_be, so I thought Alan's patches solve PR59810.
>> >> >
>> >> > What am I missing?
>> >>
>> >> Hi Christophe,
>> >>
>> >> I think probably this is our fault for making our lives way too difficult and
>> >> artificially splitting all these patches up. :)
>> >>
>> >> Alan's patch:
>> >>
>> >> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00952.html
>> >>
>> >> fixes some issues on aarch64_be, but also causes regressions. For example,
>> >>
>> >> ====
>> >> Tests that now fail, but worked before:
>> >>
>> >> aarch64_be-elf-aem: gcc.dg/vect/slp-perm-8.c -flto -ffat-lto-objects execution test
>> >> aarch64_be-elf-aem: gcc.dg/vect/slp-perm-8.c execution test
>> >> aarch64_be-elf-aem: gcc.dg/vect/vect-over-widen-1-big-array.c -flto -ffat-lto-objects execution test
>> >> ...
>> >>
>> >> Tests that now work, but didn't before:
>> >>
>> >> aarch64_be-elf-aem: gcc.dg/vect/fast-math-vect-complex-3.c execution test
>> >> aarch64_be-elf-aem: gcc.dg/vect/if-cvt-stores-vect-ifcvt-18.c execution test
>> >> aarch64_be-elf-aem: gcc.dg/vect/no-scevccp-outer-10a.c execution test
>> >> ...
>> >> ====
>> I didn't notice that because I tested Alan's patch only against the
>> advsimd-intrinsics tests.
>> In this respect, I don't understand why your ChangeLog entry says
>>        * config/aarch64/aarch64-simd.md (vec_store_lanes(o/c/x)i,
>>         vec_load_lanes(o/c/x)i): Fixed to work for Big Endian.
>> since the existing advsimd-intrinsics tests already pass with Alan's patch alone
>> or is vld1_lane still broken (for which I haven't posted a test yet)?
>>
> Yes, I think the change log is unclear and I will change it. The only thing that was
> broken was not adhering to the ABI, but we don't have any specific regression tests
> that prove this.
>
OK thanks for the clarification.


>> >> His patch is only half of the story and must be applied at the same time as the
>> >> "[AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe."
>> >> patch. With both patches applied the result looks much healthier:
>> >>
>> >> ====
>> >> # Comparing 1 common sum files
>> >> ## /bin/sh ./src/gcc/contrib/compare_tests  /tmp/gxx-sum1.10051 /tmp/gxx-sum2.10051
>> >> Tests that now work, but didn't before:
>> >>
>> >> aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer  execution test
>> >> aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer -funroll-all-loops -finline-
>> >> functions  execution test
>> >> aarch64_be-elf-aem: gcc.dg/torture/pr52028.c   -O3 -fomit-frame-pointer -funroll-loops  execution
>> test
>> >> ...
>> >> ====
>> >>
>> >> with no new regressions. After applying both patches the aarch64_be gcc testsuite is
>> >> on a parity with the aarch64 testsuite. Furthermore, after applying both of these patches:
>> >>
>> >> "[AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe"
>> >> "[AArch64] [BE] Fix vector load/stores to not use ld1/st1"
>> >>
>> >> it then becomes safe for us to remove the CCMC macro, which is the cause of
>> >> unnecessary spills to the stack for certain auto-vectorised code. So really I
>> >> suppose when I posted my second patch
>> >>
>> >> "[AArch64] [BE] [2/2] Make large opaque integer modes endianness-safe"
>> >>
>> >> I should have really just called this
>> >>
>> >> "[AArch64] [BE] Remove CCMC for aarch64"
>> >>
>> >> in order to make it clear exactly what the purpose of these patches is.
>> well, not yet since this very does not remove it :-)
>>
> Again, this is my fault as I made a mistake in the change log. If you look at the
> actual patch the CCMC macro is removed. Let me re-post corrected, more
> sensible change logs for both of those changes here:
>
> "[AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe"
> ChangeLog:
>
>     gcc/:
>     2014-10-10  David Sherwood  <david.sherwood@arm.com>
>     2014-10-10  Tejas Belagod <Tejas.Belagod@arm.com>
>
>         * config/aarch64/aarch64-protos.h (aarch64_simd_attr_length_rglist,
>         aarch64_reverse_mask): New decls.
>         * config/aarch64/iterators.md (UNSPEC_REV_REGLIST): New enum.
>         * config/aarch64/iterators.md (insn_count): New mode_attr.
>         * config/aarch64/aarch64-simd.md (vec_store_lanesoi, vec_store_lanesci,
>         vec_store_lanesxi, vec_load_lanesoi, vec_load_lanesci, vec_load_lanesxi)
>         : Made ABI compliant for Big Endian targets.
>         * config/aarch64/aarch64-simd.md (aarch64_rev_reglist, aarch64_simd_ld2,
>         aarch64_simd_ld3, aarch64_simd_ld4, aarch64_simd_st2, aarch64_simd_st3,
>         aarch64_simd_st4): Added.
>         * config/aarch64/aarch64.c (aarch64_simd_attr_length_rglist,
>         aarch64_reverse_mask): Added.
>
> "[AArch64] [BE] [2/2] Make large opaque integer modes endianness-safe"
> ChangeLog:
>
>     gcc/:
>     2014-13-10  David Sherwood  <david.sherwood@arm.com>
>     2014-13-10  Tejas Belagod <Tejas.Belagod@arm.com>
>
>         * config/aarch64/aarch64.h (CANNOT_CHANGE_MODE_CLASS): Removed.
>         * config/aarch64/aarch64.c (aarch64_cannot_change_mode_class): Removed.
>         * config/aarch64/aarch64-protos.h (aarch64_cannot_change_mode_class):
>         Removed.
>
> Again, apologies for the confusion,
> David.
>
>> >>
>> >> Kind Regards,
>> >> David Sherwood.
>> >
>> >
>> >
>> >
>
>
>
>

Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[Tejas Belagod]

On 20/11/14 18:19, Marcus Shawcroft wrote:
> On 13 November 2014 10:09, David Sherwood <david.sherwood@arm.com> wrote:
>
>>      gcc/:
>>      2014-11-13  David Sherwood  <david.sherwood@arm.com>
>>
>>          * config/aarch64/aarch64-protos.h (aarch64_simd_attr_length_rglist,
>>          aarch64_reverse_mask): New decls.
>>          * config/aarch64/iterators.md (UNSPEC_REV_REGLIST): New enum.
>>          * config/aarch64/iterators.md (insn_count): New mode_attr.
>>         * config/aarch64/aarch64-simd.md (vec_store_lanes(o/c/x)i,
>>          vec_load_lanes(o/c/x)i): Fixed to work for Big Endian.
>
> Spell these out in full please, some folks like to be able to grep for
> function names in these logs.
>
>>          * config/aarch64/aarch64-simd.md (aarch64_rev_reglist,
>>          aarch64_simd_(ld/st)(2/3/4)): Added.
>
> Likewise.
>
>>          * config/aarch64/aarch64.c (aarch64_simd_attr_length_rglist,
>>          aarch64_reverse_mask): Added.
>
> It isn;t clear to me how far through the various BE patches we need to
> get before 59810 is actually resolved?

David's 2 patches

https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01431.html
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01099.html

and Alan's 2 patches:

https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02797.html
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01087.html

should fix 59810.

Thanks,
Tejas.

Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[Marcus Shawcroft]

On 17 December 2014 at 15:15, Tejas Belagod <tejas.belagod@arm.com> wrote:

>> It isn;t clear to me how far through the various BE patches we need to
>> get before 59810 is actually resolved?
>
>
> David's 2 patches
>
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01431.html
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01099.html
>
> and Alan's 2 patches:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02797.html

OK, thanks, my understanding is that all of the above are now blocked
waiting some resolution on this patch to rtlanal.c:

> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01087.html

/Marcus

Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[Tejas Belagod]

On 17/12/14 16:46, Marcus Shawcroft wrote:
> On 17 December 2014 at 15:15, Tejas Belagod <tejas.belagod@arm.com> wrote:
>
>>> It isn;t clear to me how far through the various BE patches we need to
>>> get before 59810 is actually resolved?
>>
>>
>> David's 2 patches
>>
>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01431.html
>> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01099.html
>>
>> and Alan's 2 patches:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02797.html
>
> OK, thanks, my understanding is that all of the above are now blocked
> waiting some resolution on this patch to rtlanal.c:

I believe so.

Thanks,
Tejas.

>
>> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01087.html
>
> /Marcus
>

Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[Christophe Lyon]

On 17 December 2014 at 18:02, Tejas Belagod <tejas.belagod@arm.com> wrote:
> On 17/12/14 16:46, Marcus Shawcroft wrote:
>>
>> On 17 December 2014 at 15:15, Tejas Belagod <tejas.belagod@arm.com> wrote:
>>
>>>> It isn;t clear to me how far through the various BE patches we need to
>>>> get before 59810 is actually resolved?
>>>
>>>
>>>
>>> David's 2 patches
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01431.html
>>> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01099.html
>>>
>>> and Alan's 2 patches:
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02797.html
>>
>>
>> OK, thanks, my understanding is that all of the above are now blocked
>> waiting some resolution on this patch to rtlanal.c:
>
>
> I believe so.
>
> Thanks,
> Tejas.
>

Hi,
If I'm not mistaken, this has been committed as r219959, and is
causing regressions on aarch64_be for several AdvSimd intrinsic tests:
vldX_lane, vtrn, vuzp, vzip, as well as vldN_1 and vstN_1

See:
http://abe.tcwglab.linaro.org/logs/validations/cross-validation/gcc/trunk/219959/report-build-info.html

These tests started passing at the previous commit (r219958) with the
other half of this patch.

I haven't looked at the details yet.

Christophe.

>>
>>> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01087.html
>>
>>
>> /Marcus
>>
>
>

Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[Christophe Lyon]

On 25 January 2015 at 22:33, Christophe Lyon <christophe.lyon@linaro.org> wrote:
> On 17 December 2014 at 18:02, Tejas Belagod <tejas.belagod@arm.com> wrote:
>> On 17/12/14 16:46, Marcus Shawcroft wrote:
>>>
>>> On 17 December 2014 at 15:15, Tejas Belagod <tejas.belagod@arm.com> wrote:
>>>
>>>>> It isn;t clear to me how far through the various BE patches we need to
>>>>> get before 59810 is actually resolved?
>>>>
>>>>
>>>>
>>>> David's 2 patches
>>>>
>>>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01431.html
>>>> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01099.html
>>>>
>>>> and Alan's 2 patches:
>>>>
>>>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02797.html
>>>
>>>
>>> OK, thanks, my understanding is that all of the above are now blocked
>>> waiting some resolution on this patch to rtlanal.c:
>>
>>
>> I believe so.
>>
>> Thanks,
>> Tejas.
>>
>
> Hi,
> If I'm not mistaken, this has been committed as r219959, and is
> causing regressions on aarch64_be for several AdvSimd intrinsic tests:
> vldX_lane, vtrn, vuzp, vzip, as well as vldN_1 and vstN_1
>
> See:
> http://abe.tcwglab.linaro.org/logs/validations/cross-validation/gcc/trunk/219959/report-build-info.html
>
> These tests started passing at the previous commit (r219958) with the
> other half of this patch.
>
> I haven't looked at the details yet.
>

I've been looking at these failures for some time. I currently have a
patch which mostly reverts the one discussed in this thread, and makes
the AdvSIMD tests pass.

However, it creates regressions in some of the vectorizer tests. When
r219959 was committed, I observed that these tests started to pass:
gcc.dg/torture/pr52028.c
gcc.dg/torture/pr53366-1.c
gcc.dg/vect/pr37539.c
gcc.dg/vect/pr40074.c
gcc.dg/vect/pr51074.c
gcc.dg/vect/pr59354.c
gcc.dg/vect/pr64252.c
gcc.dg/vect/slp-12b.c
gcc.dg/vect/slp-19b.c
gcc.dg/vect/slp-perm-8.c
gcc.dg/vect/slp-perm-9.c
gcc.dg/vect/vect-107.c
gcc.dg/vect/vect-over-widen-1-big-array.c
gcc.dg/vect/vect-over-widen-1.c
gcc.dg/vect/vect-over-widen-2-big-array.c
gcc.dg/vect/vect-over-widen-2.c
gcc.dg/vect/vect-over-widen-3-big-array.c
gcc.dg/vect/vect-over-widen-3.c
gcc.dg/vect/vect-over-widen-4-big-array.c
gcc.dg/vect/vect-over-widen-4.c
gcc.dg/vect/vect-strided-store-a-u8-i2.c
gcc.dg/vect/vect-strided-store-u16-i4.c
gcc.dg/vect/vect-strided-store-u32-i2.c
gcc.dg/vect/vect-strided-u16-i3.c

I am looking at the pr59354.c testcase, which seems to be one the
simplest showing a regression. The vectorizer does a pretty good at
generating obfuscated code :-) and I find it quite difficult to debug,
given the lack of debug environment.

In fact, I still don't understand what r219959 actually fixed. I
believe that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810 is
covered by the AdvSIMD tests, which r219959 actually breaks.

In summary, I have the feeling that r219959 should be somewhat
reverted such that the AdvSIMD tests pass on aarch64_be, but that this
would expose a bug related to vectorization.

Any advice appreciated.

Thanks,

Christophe.

> Christophe.
>
>>>
>>>> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01087.html
>>>
>>>
>>> /Marcus
>>>
>>
>>