--- Comment #3 from Michael Matz <matz at gcc dot> 2010-09-24 13:37:04 
UTC ---
The problem is how the alignment for the read accesses is computed.
When we vectorize this data_ref:
  ibuf[64 - i]   (0 <= i < 64)
  ibuf[64 .. 1]
The first access is to ibuf[64], which is aligned to 16 just fine.
But when accessing multiple elements (ibuf[64 .. 61]) the actual
base address will be &ibuf[61], which is not aligned to 16 bytes.

I think the code in vectorizable_load that tries to recompute alignment
info from the underlying scalar pointers is incorrect.  We currently have:

                pi = get_ptr_info (dataref_ptr);
                pi->align = TYPE_ALIGN_UNIT (vectype);
                if (alignment_support_scheme == dr_aligned)
                    gcc_assert (aligned_access_p (first_dr));
                    pi->misalign = 0;
                else if (DR_MISALIGNMENT (first_dr) == -1)
                    TREE_TYPE (data_ref)
                      = build_aligned_type (TREE_TYPE (data_ref),
                                            TYPE_ALIGN (TREE_TYPE (vectype)));
                    pi->align = TYPE_ALIGN_UNIT (TREE_TYPE (vectype));
                    pi->misalign = 0;
                    TREE_TYPE (data_ref)
                      = build_aligned_type (TREE_TYPE (data_ref),
                                            TYPE_ALIGN (TREE_TYPE (vectype)));
                    pi->misalign = DR_MISALIGNMENT (first_dr);

dataref_ptr will be the vector pointer.  One problem is that for the
testcase alignment_support_scheme is set to dr_aligned.  That is because
DR_MISALIGNMENT of first_dr is zero.  But first_dr is in terms of the scalar
type, so it seems problematic to use that to assess if the vectorized
access is also aligned.  OTOH that is historic code.

But even if we would fix that (set alignment_support_scheme to 
dr_unaligned_supported) the code above would do the wrong thing.
DR_MISALIGNMENT (first_dr) is zero, so pi->align would remain at the
(large) alignment of the vector type, and it's misalignment (which was with
respect to the smaller scalar type) would be copied over, also be zero,
and therefore wrong.

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Reply via email to