diff mbox

[PR,54051,ARM] Fix alignment specifier alignment information for ARM.

Message ID CACUk7=X8QpHgWAvCTMeE8xfKrRpRMeo7KeAArb0XFOrObP5eiQ@mail.gmail.com
State New
Headers show

Commit Message

Ramana Radhakrishnan July 24, 2012, 12:09 p.m. UTC
Hi ,


          While testing my neon intrinsics work with some testcases
that I was writing up, I ran into PR54051 . The one change which is
probably a bit long standing is the fact that for register only
addressing modes i.e. something like mem (reg:SI) we were printing out
addresses with an immediate of #0. Historically the reason for this
appears to be to deal with an assembler bug of yesteryears where the
assembler couldn't  sometimes properly distinguish between auto-inc
addressing forms and the register indirect addressing form which I'm
informed is fixed. This patch has gone through a full test run with
qemu in a cross environment with no regressions for armv7-a / neon /
arm/ thumb with a v5t multilib for c, c++ .

I intend to backport this to 4.7 as this is a regression compared to
4.6, after letting it be on trunk for a few days to see if the
auto-testers pick anything else up unless there is an objection from
anyone.

regards
Ramana




	PR target/54051
	* config/arm/arm.c (arm_print_operand_address): Remove superfluous
	printing of #0.
	* config/arm/neon.md ("neon_vld3_lane<mode>":VD): Remove alignment
	specifier.
	("neon_vld3_lane<mode>":VMQ): Likewise.
	("neon_vld3_dup<mode>":VDX): Likewise.
	("neon_vst3_lane<mode>":VD): Likewise.
	("neon_vst3_lane<mode>":VMQ): Likewise.


	PR target/54051
	* gcc.target/arm/pr54051.c: New.
	* gcc.target/arm/vfp-1.c: Adjust test.

Comments

Ye Joey Feb. 5, 2013, 7:43 a.m. UTC | #1
Ramana,

This issue also impacts ldrexh/ldrexb, as assembler doesn't accept
ldrexh r1, [r0, #0]. May it be backported to 4.7 by now?

Thanks - Joey

On Tue, Jul 24, 2012 at 8:09 PM, Ramana Radhakrishnan
<ramana.radhakrishnan@linaro.org> wrote:
> Hi ,
>
>
>           While testing my neon intrinsics work with some testcases
> that I was writing up, I ran into PR54051 . The one change which is
> probably a bit long standing is the fact that for register only
> addressing modes i.e. something like mem (reg:SI) we were printing out
> addresses with an immediate of #0. Historically the reason for this
> appears to be to deal with an assembler bug of yesteryears where the
> assembler couldn't  sometimes properly distinguish between auto-inc
> addressing forms and the register indirect addressing form which I'm
> informed is fixed. This patch has gone through a full test run with
> qemu in a cross environment with no regressions for armv7-a / neon /
> arm/ thumb with a v5t multilib for c, c++ .
>
> I intend to backport this to 4.7 as this is a regression compared to
> 4.6, after letting it be on trunk for a few days to see if the
> auto-testers pick anything else up unless there is an objection from
> anyone.
>
> regards
> Ramana
>
>
>
>
>         PR target/54051
>         * config/arm/arm.c (arm_print_operand_address): Remove superfluous
>         printing of #0.
>         * config/arm/neon.md ("neon_vld3_lane<mode>":VD): Remove alignment
>         specifier.
>         ("neon_vld3_lane<mode>":VMQ): Likewise.
>         ("neon_vld3_dup<mode>":VDX): Likewise.
>         ("neon_vst3_lane<mode>":VD): Likewise.
>         ("neon_vst3_lane<mode>":VMQ): Likewise.
>
>
>         PR target/54051
>         * gcc.target/arm/pr54051.c: New.
>         * gcc.target/arm/vfp-1.c: Adjust test.
Ramana Radhakrishnan Feb. 5, 2013, 2:01 p.m. UTC | #2
On 02/05/13 07:43, Ye Joey wrote:
> Ramana,
>
> This issue also impacts ldrexh/ldrexb, as assembler doesn't accept
> ldrexh r1, [r0, #0]. May it be backported to 4.7 by now?
>
> Thanks - Joey

Ok by me unless RM's object. It's been on trunk long enough and hasn't 
caused any issues that I'm aware of.

Thanks for bringing this up. It looks like it slipped through the cracks 
when I left Linaro.

regards
Ramana
>
> On Tue, Jul 24, 2012 at 8:09 PM, Ramana Radhakrishnan
> <ramana.radhakrishnan@linaro.org> wrote:
>> Hi ,
>>
>>
>>            While testing my neon intrinsics work with some testcases
>> that I was writing up, I ran into PR54051 . The one change which is
>> probably a bit long standing is the fact that for register only
>> addressing modes i.e. something like mem (reg:SI) we were printing out
>> addresses with an immediate of #0. Historically the reason for this
>> appears to be to deal with an assembler bug of yesteryears where the
>> assembler couldn't  sometimes properly distinguish between auto-inc
>> addressing forms and the register indirect addressing form which I'm
>> informed is fixed. This patch has gone through a full test run with
>> qemu in a cross environment with no regressions for armv7-a / neon /
>> arm/ thumb with a v5t multilib for c, c++ .
>>
>> I intend to backport this to 4.7 as this is a regression compared to
>> 4.6, after letting it be on trunk for a few days to see if the
>> auto-testers pick anything else up unless there is an objection from
>> anyone.
>>
>> regards
>> Ramana
>>
>>
>>
>>
>>          PR target/54051
>>          * config/arm/arm.c (arm_print_operand_address): Remove superfluous
>>          printing of #0.
>>          * config/arm/neon.md ("neon_vld3_lane<mode>":VD): Remove alignment
>>          specifier.
>>          ("neon_vld3_lane<mode>":VMQ): Likewise.
>>          ("neon_vld3_dup<mode>":VDX): Likewise.
>>          ("neon_vst3_lane<mode>":VD): Likewise.
>>          ("neon_vst3_lane<mode>":VMQ): Likewise.
>>
>>
>>          PR target/54051
>>          * gcc.target/arm/pr54051.c: New.
>>          * gcc.target/arm/vfp-1.c: Adjust test.
>
diff mbox

Patch

Index: gcc/testsuite/gcc.target/arm/pr54051.c
===================================================================
--- gcc/testsuite/gcc.target/arm/pr54051.c	(revision 0)
+++ gcc/testsuite/gcc.target/arm/pr54051.c	(revision 189808)
@@ -0,0 +1,20 @@ 
+/* { dg-do assemble }  */
+/* { dg-require-effective-target arm_neon }  */
+/* { dg-options "-O2" }  */
+/* { dg-add-options arm_neon }  */
+
+#include <arm_neon.h>
+
+int32_t a __attribute__ ((aligned (64)));
+
+int32x2x3_t test (void)
+{
+  return vld3_dup_s32 (&a);
+}
+
+int32x2x3_t test1 (void)
+{
+  int32x2x3_t res ;
+  return vld3_lane_s32 (&a, res, 1);
+}
+
Index: gcc/testsuite/gcc.target/arm/vfp-1.c
===================================================================
--- gcc/testsuite/gcc.target/arm/vfp-1.c	(revision 189807)
+++ gcc/testsuite/gcc.target/arm/vfp-1.c	(revision 189808)
@@ -129,7 +129,7 @@ 
   /* { dg-final { scan-assembler "flds.+ \\\[r0, #1020\\\]" } } */
   /* { dg-final { scan-assembler "flds.+ \\\[r\[0-9\], #-1020\\\]" { target { arm32 && { ! arm_thumb2_ok } } } } } */
   /* { dg-final { scan-assembler "add.+ r0, #1024" } } */
-  /* { dg-final { scan-assembler "fsts.+ \\\[r\[0-9\], #0\\\]\n" } } */
+  /* { dg-final { scan-assembler "fsts.+ \\\[r\[0-9\]\\\]\n" } } */
   f[256] = f[255] + f[-255];
 
   /* { dg-final { scan-assembler "fldd.+ \\\[r1, #1016\\\]" } } */
Index: gcc/config/arm/arm.c
===================================================================
--- gcc/config/arm/arm.c	(revision 189807)
+++ gcc/config/arm/arm.c	(revision 189808)
@@ -17420,7 +17420,7 @@ 
       int is_minus = GET_CODE (x) == MINUS;
 
       if (GET_CODE (x) == REG)
-	asm_fprintf (stream, "[%r, #0]", REGNO (x));
+	asm_fprintf (stream, "[%r]", REGNO (x));
       else if (GET_CODE (x) == PLUS || is_minus)
 	{
 	  rtx base = XEXP (x, 0);
Index: gcc/config/arm/neon.md
===================================================================
--- gcc/config/arm/neon.md	(revision 189807)
+++ gcc/config/arm/neon.md	(revision 189808)
@@ -4806,7 +4806,7 @@ 
   ops[2] = gen_rtx_REG (DImode, regno + 4);
   ops[3] = operands[1];
   ops[4] = operands[3];
-  output_asm_insn ("vld3.<V_sz_elem>\t{%P0[%c4], %P1[%c4], %P2[%c4]}, %A3",
+  output_asm_insn ("vld3.<V_sz_elem>\t{%P0[%c4], %P1[%c4], %P2[%c4]}, %3",
                    ops);
   return "";
 }
@@ -4838,7 +4838,7 @@ 
   ops[2] = gen_rtx_REG (DImode, regno + 8);
   ops[3] = operands[1];
   ops[4] = GEN_INT (lane);
-  output_asm_insn ("vld3.<V_sz_elem>\t{%P0[%c4], %P1[%c4], %P2[%c4]}, %A3",
+  output_asm_insn ("vld3.<V_sz_elem>\t{%P0[%c4], %P1[%c4], %P2[%c4]}, %3",
                    ops);
   return "";
 }
@@ -4860,7 +4860,7 @@ 
       ops[1] = gen_rtx_REG (DImode, regno + 2);
       ops[2] = gen_rtx_REG (DImode, regno + 4);
       ops[3] = operands[1];
-      output_asm_insn ("vld3.<V_sz_elem>\t{%P0[], %P1[], %P2[]}, %A3", ops);
+      output_asm_insn ("vld3.<V_sz_elem>\t{%P0[], %P1[], %P2[]}, %3", ops);
       return "";
     }
   else
@@ -4978,7 +4978,7 @@ 
   ops[2] = gen_rtx_REG (DImode, regno + 2);
   ops[3] = gen_rtx_REG (DImode, regno + 4);
   ops[4] = operands[2];
-  output_asm_insn ("vst3.<V_sz_elem>\t{%P1[%c4], %P2[%c4], %P3[%c4]}, %A0",
+  output_asm_insn ("vst3.<V_sz_elem>\t{%P1[%c4], %P2[%c4], %P3[%c4]}, %0",
                    ops);
   return "";
 }
@@ -5010,7 +5010,7 @@ 
   ops[2] = gen_rtx_REG (DImode, regno + 4);
   ops[3] = gen_rtx_REG (DImode, regno + 8);
   ops[4] = GEN_INT (lane);
-  output_asm_insn ("vst3.<V_sz_elem>\t{%P1[%c4], %P2[%c4], %P3[%c4]}, %A0",
+  output_asm_insn ("vst3.<V_sz_elem>\t{%P1[%c4], %P2[%c4], %P3[%c4]}, %0",
                    ops);
   return "";
 }