Auto-vectorizer and (mis-)alignment support assumptions

[Richard Biener]

On Thu, Sep 12, 2013 at 11:59 AM, Frederic Riss <frederic.riss@gmail.com> wrote:
> On 12 September 2013 11:25, Richard Biener <richard.guenther@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