[PATCH] D46042: Cap vector alignment at 16 for all Darwin platforms
John McCall via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Jun 4 15:17:12 PDT 2018
rjmccall added a comment.
In https://reviews.llvm.org/D46042#1121648, @rnk wrote:
> It's the typedef alignment changes that are causing problems for us, not the MaxVectorAlign changes. That makes more sense. The new alignment attribute breaks our implementation of `_mm256_loadu_ps`, because the packed struct ends up with a 32-byte alignment. Here's the implementation:
>
> static __inline __m256 __DEFAULT_FN_ATTRS
> _mm256_loadu_ps(float const *__p)
> {
> struct __loadu_ps {
> __m256 __v;
> } __attribute__((__packed__, __may_alias__));
> return ((struct __loadu_ps*)__p)->__v;
> }
>
>
> And clang's -fdump-record-layouts says:
>
> *** Dumping AST Record Layout
> 0 | struct __loadu_ps
> 0 | __m256 __v
> | [sizeof=32, align=32]
>
>
> I think the problem is that `__attribute__((aligned(N)))` beats `__attribute__((packed))` on Windows to match MSVC's behavior with `__declspec(align(N))`.
>
> I think we should revert this for now. Adding the alignment attribute to all Intel vector typedefs is a bigger change than it seems.
Ugh. That is just an awful language rule. Would it be reasonable to restrict it to only attributes spelled with `__declspec(align(N))` rather than `__attribute__((aligned(N)))`, or is that too invasive in the alignment computation?
Repository:
rC Clang
https://reviews.llvm.org/D46042
More information about the cfe-commits
mailing list