This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Auto-vectorizer and (mis-)alignment support assumptions
- From: Frederic Riss <frederic dot riss at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>
- Date: Thu, 12 Sep 2013 11:59:45 +0200
- Subject: Re: Auto-vectorizer and (mis-)alignment support assumptions
- Authentication-results: sourceware.org; auth=none
- References: <CAKk_3s_aZUj9=EVoC1fjR2F98Wxm-3R62BsEuYD14ODWZYVmFA at mail dot gmail dot com> <CAFiYyc0_6FahQ3CPnRVnEKJN0FdN0W0v9xAjM_R7zLfjZtDvCA at mail dot gmail dot com>
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?
Thanks,
Fred