Hi,
This fixes a latent issue in arm_print_operand where we would have
generated a 128 bit alignment hint for any neon instruction that used
the %A notation for printing memory addresses.
Given that you can never have the load of a 64 bit quantity with an
128 bit alignment (indeed the list of instructions that I could think
of that we might generate for this purpose is as below.)
vld1.8 d0, [r0]
vld1.16 d0, [r0]
vld1.32 d0, [r0]
vld1.64 d0, [r0]
vld2.32 {d0[0], d1[0]}, [r0]
vld4.16 {d0[0], d1[0], d2[0], D3[0]}, [r0]
This is not an issue today for the following reasons :
>From the list above:
1. The first 4 instructions will not come out of the compiler today
(we put out vldr's or vldmia) instructions for auto-vectorized code.
Indeed I found this only when I replaced the vldmia's and the vldr's
with vld1's.
2. The last 2 instructions only come out of intrinsics. The first
4 will also get generated with the intrinsics but .....
we get away with this because of the type punning in arm_neon.h
Even in the event we use this in that form, I doubt
if we'll ever change that situation.
I was able to trigger this when I tried to get the backend to generate
vld1.64 instructions for appropriate vector modes instead of vldmia
/ vstmia in little endian configurations. (That will follow once
testing completes)
Ok ?
cheers
Ramana
2011-12-08 Ramana Radhakrishnan <[email protected]>
* config/arm/arm.c (arm_print_operand): Only allow hints
of 128 bits for 16 byte loads.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index d1d0c22..bfdac51 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -17654,8 +17654,8 @@ arm_print_operand (FILE *stream, rtx x, int code)
/* Only certain alignment specifiers are supported by the hardware. */
if (memsize == 16 && (align % 32) == 0)
align_bits = 256;
- else if ((memsize == 8 || memsize == 16) && (align % 16) == 0)
- align_bits = 128;
+ else if ((memsize == 16) && (align % 16) == 0)
+ align_bits = 128;
else if ((align % 8) == 0)
align_bits = 64;
else
