search for: islegalmaskedload

...hose instructions. I don't want to touch the source code. Best, Zhi On Fri, Jan 22, 2016 at 4:54 PM, Sanjay Patel <spatel at rotateright.com> wrote: > I was just looking at the related masked load/store operations, and I > think there are at least 2 bugs: > > 1. X86TTIImpl::isLegalMaskedLoad/Store() should be legal for FP types with > AVX1 (not just AVX2). > 2. X86TTIImpl::isLegalMaskedGather/Scatter() should be legal for 128/256 > bit vectors with AVX2 (not just AVX512). > > I looked at this for the first time today, so I may be missing something... > > So for the...

...isInfo. Eventually, I'd like to see these under Analysis subtree (instead of Transform), since they are indeed Analysis. As a first step of this LoopVectorizationLegality cleanup, I propose to move the following checks (and member functions) to LoopVectorizationCostModel. isLegalMaskedStore isLegalMaskedLoad isLegalMaskedScatter isLegalMaskedGather My assumption is that all SIMD architectures should support serialization of those operations at some cost (e.g., lowering in CG prepare) and thus failing to vectorize due to "false" return values of those calls is incorrect behavior. I'll...

Hi, I used clang -O3 -c -emit-llvm on the follow code to generate a bitcode, say a.bc. I read the .ll file and didn't see any gather intrinsic. Also, I used opt -O3 -mcpu=core-avx2/-mcpu=skx, but there is still no gather intrinsic generated. int foo(int A[800], int B[800], int C[800]) { for (int i = 0; i < 800; i++) { A[B[i]] = i + 5; } for (int i = 0; i < 800;

...9;d like to see these under Analysis subtree (instead of Transform), since they are indeed Analysis. > > As a first step of this LoopVectorizationLegality cleanup, I propose to move the following checks > (and member functions) to LoopVectorizationCostModel. > isLegalMaskedStore > isLegalMaskedLoad > isLegalMaskedScatter > isLegalMaskedGather > My assumption is that all SIMD architectures should support serialization of those operations > at some cost (e.g., lowering in CG prepare) and thus failing to vectorize due to "false" return values > of those calls is incor...

...;d like to see these under Analysis subtree (instead of Transform), since they are indeed Analysis. > > As a first step of this LoopVectorizationLegality cleanup, I propose > to move the following checks (and member functions) to LoopVectorizationCostModel. > isLegalMaskedStore > isLegalMaskedLoad > isLegalMaskedScatter > isLegalMaskedGather > My assumption is that all SIMD architectures should support > serialization of those operations at some cost (e.g., lowering in CG > prepare) and thus failing to vectorize due to "false" return values of > those calls...

...se under Analysis subtree (instead of Transform), since they are indeed Analysis. >> >> As a first step of this LoopVectorizationLegality cleanup, I propose >> to move the following checks (and member functions) to LoopVectorizationCostModel. >> isLegalMaskedStore >> isLegalMaskedLoad >> isLegalMaskedScatter >> isLegalMaskedGather >> My assumption is that all SIMD architectures should support >> serialization of those operations at some cost (e.g., lowering in CG >> prepare) and thus failing to vectorize due to "false" return values of...

...e under Analysis subtree (instead of Transform), since they are indeed Analysis. >> >> As a first step of this LoopVectorizationLegality cleanup, I propose >> to move the following checks (and member functions) to LoopVectorizationCostModel. >> isLegalMaskedStore >> isLegalMaskedLoad >> isLegalMaskedScatter >> isLegalMaskedGather >> My assumption is that all SIMD architectures should support >> serialization of those operations at some cost (e.g., lowering in CG >> prepare) and thus failing to vectorize due to "false" return values &...

Hi, > On Apr 22, 2016, at 8:27 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Rob, > > The problem here is that the d[i] array is only conditionally accessed, and so we can't if-convert the loop body. The compiler does not know that d[i] is actually dereferenceable for all i from 0 to 15 (the array might be shorter and p[i] is 0 for i past the end

...don't want to touch the source code. Best, Zhi On Fri, Jan 22, 2016 at 4:54 PM, Sanjay Patel <spatel at rotateright.com<mailto:spatel at rotateright.com>> wrote: I was just looking at the related masked load/store operations, and I think there are at least 2 bugs: 1. X86TTIImpl::isLegalMaskedLoad/Store() should be legal for FP types with AVX1 (not just AVX2). 2. X86TTIImpl::isLegalMaskedGather/Scatter() should be legal for 128/256 bit vectors with AVX2 (not just AVX512). I looked at this for the first time today, so I may be missing something... So for the moment, the answer to your questi...