http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47397
--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-21
15:35:29 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > Thus, the real reason is that we lack alignment information on
> > MEM_REFs/TARGET_MEM_REFs but only have pointer alignment information for
> > now.
>
> I know it won't solve this bug. But shouldn't we at least use alignment
> of array element instead of pointer alignment?
Well, part of it is half-way re-introducing type-alignment stuff,
deviating from the intial conservative-correctness.
Thus, we run into
align = MAX (TYPE_ALIGN (TREE_TYPE (exp)),
get_object_alignment (exp, BIGGEST_ALIGNMENT));
for deciding whether to use movmisalign_optab but in set_mem_attrs_minus_bitpos
we do not fall back to TYPE_ALIGNment at all (which is conservative and
by initial design).
You might argue we want consistency here.
Note that this shouldn't be an issue for AVX/SSE as unaligned moves are
as fast as aligned ones if they are really aligned (at least I hope
this is true for AVX, it definitely is for SSE on recent archs - if not
the vectorizer cost model would need adjustment).
