On Thu, Sep 12, 2013 at 11:59 AM, Frederic Riss <frederic.r...@gmail.com> wrote: > On 12 September 2013 11:25, Richard Biener <richard.guent...@gmail.com> wrote: >> You may simply hit some bug in the vectorizer. The vectorizer assumes >> it can re-align local decls, and for the above it should use >> known-misalignment >> accesses. You can check with -fdump-rtl-expand-details-alias what the >> MEMs think they are aligned to (and with -fdump-tree-vect-alias what the >> vectorizer thinks it created). > > You're right, there seems to be a bug there: > > # PT = anything > # ALIGN = 8, MISALIGN = 0 > # vect_pdata.15_33 = PHI <vect_pdata.15_34(5), vect_pdata.18_32(3)> > # PT = anything > # ALIGN = 8, MISALIGN = 0 > # vect_pdata.20_37 = PHI <vect_pdata.20_38(5), vect_pdata.23_36(3)> > > And even more obvious at the RTL level: > > (insn 83 82 84 5 (set (reg:V2SI 229) > (mem:V2SI (reg/f:SI 206 [ D.1518 ]) [2 MEM[base: D.1518_64, > offset: 0B]+0 S8 A64])) vect.c:12 -1 > (nil)) > > (insn 84 83 85 5 (set (mem:V2SI (plus:SI (reg/f:SI 206 [ D.1518 ]) > (const_int 12 [0xc])) [2 MEM[base: D.1518_64, offset: > 12B]+0 S8 A64]) > (reg:V2SI 229)) vect.c:12 -1 > (nil)) > > The MEMs with same base but offsets 0 and 12 can't both be A64. Any > idea where to look next?
Look at the -fdump-tree-vect-details, it should print what it does during alignment analysis. Then debug the code ... Richard. > Thanks, > Fred
