On 12 September 2013 11:25, Richard Biener <[email protected]> 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?
Thanks,
Fred
