[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