http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54252
--- Comment #2 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> 2012-08-15
11:18:12 UTC ---
(In reply to comment #1)
> hmmm MEM_SIZE for the offending load appears to be 32 bytes. Something is
> fishy
> here.
>
> vld1.32 {d16}, [r3:128]! <= Offending load
(insn 13 12 0 (set (reg:V2SF 112 [ D.14059 ])
(unspec:V2SF [
(mem/u/c:V2SF (reg:SI 125) [0 MEM[(const float32_t[8] *)&consts
+ 16B]+0 S32 A128])
] UNSPEC_VLD1))
/home/ramrad01/sources/fsf/build-sanity/gcc/include/arm_neon.h:7908 -1
(nil))
As you can see it appears to think that the size of the load is what's in
MEM_SIZE . However that wouldn't be the case here as we are only loading
V2SFmode values but the underlying address is the address of what is an array
of 8 float32_t values.
This thoroughly untested appears to work around the problem but I don't like
this one bit.
Index: gcc/config/arm/arm.c
===================================================================
--- gcc/config/arm/arm.c (revision 190409)
+++ gcc/config/arm/arm.c (working copy)
@@ -17320,7 +17320,10 @@
instruction (for some alignments) as an aid to the memory subsystem
of the target. */
align = MEM_ALIGN (x) >> 3;
- memsize = MEM_SIZE (x);
+ if (MEM_SIZE_KNOWN_P (x))
+ memsize = MIN (MEM_SIZE (x), GET_MODE_SIZE (GET_MODE (x)));
+ else
+ memsize = 0;
/* Only certain alignment specifiers are supported by the hardware. */
if (memsize == 32 && (align % 32) == 0)
regards,
Ramana
