This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/54252] [Neon] Bad alignment code generated for Neon loads


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]