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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
