rnk added a comment.
By the way, I went ahead and reverted this in r333958.
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
rnk added a comment.
In https://reviews.llvm.org/D46042#1121674, @rjmccall wrote:
> > 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 t
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
rnk added a comment.
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 imp
rnk added a comment.
This change appears to have caused some blink vector math unit tests to fail on
Windows. We are tracking it at https://crbug.com/849251.
It has a pretty small reproducer:
#include
__m256 loadit(__m256 *p) { return _mm256_loadu_ps((const float *)p); }
Compile for x86_6
rjmccall closed this revision.
rjmccall added a comment.
Landed as r333791.
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
rjmccall added a comment.
In https://reviews.llvm.org/D46042#1088049, @scanon wrote:
> In https://reviews.llvm.org/D46042#1088044, @ab wrote:
>
> > So, this makes sense to me, but on x86, should we also be worried about the
> > fact that the calling convention is based on which features are avai
rjmccall added a comment.
In https://reviews.llvm.org/D46042#1088044, @ab wrote:
> So, this makes sense to me, but on x86, should we also be worried about the
> fact that the calling convention is based on which features are available?
> (>128bit ext_vector_types are passed in AVX/AVX-512 regi
scanon added a comment.
In https://reviews.llvm.org/D46042#1088044, @ab wrote:
> So, this makes sense to me, but on x86, should we also be worried about the
> fact that the calling convention is based on which features are available?
> (>128bit ext_vector_types are passed in AVX/AVX-512 regist
ab added a comment.
So, this makes sense to me, but on x86, should we also be worried about the
fact that the calling convention is based on which features are available?
(>128bit ext_vector_types are passed in AVX/AVX-512 registers, if available).
Presumably swift is also affected, no?
Rep
rjmccall added a comment.
I think we should seriously consider making alignment attributes on typedefs
(and maybe some other attributes like may_alias) actual type qualifiers that
are preserved in the canonical type, mangled, and so on. It would be an ABI
break, but it'd also solve a lot of pr
ahatanak added a comment.
> Note that this sort of attribute is stripped from template arguments in
> template substitution, so there's a possibility that code templated over
> vectors will produce inadequately-aligned objects.
I was wondering whether there is a warning clang issues when the al
ahatanak accepted this revision.
ahatanak added a comment.
This revision is now accepted and ready to land.
LGTM
Repository:
rC Clang
https://reviews.llvm.org/D46042
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cg
rjmccall created this revision.
Herald added a reviewer: javed.absar.
Herald added subscribers: cfe-commits, kristof.beyls.
This fixes two major problems:
- We were not capping vector alignment as desired on 32-bit ARM.
- We were using different alignments based on the AVX settings on Intel, so w
14 matches
Mail list logo
