search for: v8f64

...> gather intrinsic if there is something wrong with the way I am using it? > > Modulo obvious typos, the snippets look like they ought to work (on > trunk at least). Do you have an actual .ll or .bc and llc invocation > that fails? Only typo that caught my eye is ‘llvm.masked.gather.v8f64’ which should have v2 instead of v8 to match the <2 x double> Could that be the problem? Cheers, Pete > > Cheers. > > Tim. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/...

...x double*> undef, double* %a, i32 0 %brcst.a = shufflevector <2 x double*> % splat.a, <2 x double*> undef, <2 x i32> zeroinitializer %gep.addr = getelementptr <2 x double*> % brcst.a, <2 x i64> zeroinitializer %1_gather = call <2 x double> @llvm.masked.gather.v8f64(<2 x double*> %gep.addr, i32 8, <2 x i1> <i1 true, i1, true>, <2 x double> undef) I could load my pass successfully with opt, but I got the following errors when I either run the new bitcode using lli or generate the assembly using llc: PromoteIntegerOperand Op #2: 0x41bf3...

I 100% get that we might not like the decisions clang-format is making, but how does one overcome this when adding new code? The pre-merge checks enforce clang-formatting before commit and that's a common review comment anyway for those who didn't join the pre-merge checking group. I'm just wondering are we not all following the same guidelines? Concerns of clang-format not being good

...(this is more difficult as the type is not encoded). I'm guessing that the cost model would then make VF=4 cheaper, so generating calls to __svml_sin_4 (I'm not in work so can't check). If the vectorization factor was forced to 8, we'll either get a call to the intrinsic llvm.sin.v8f64 (if no-math-errno) or the vectorizer will scalarize the call. The vectorizer would not generate two calls to __svml_sin_4 although this would be cheaper. While this problem probably doesn't require the loop vectorizer to have knowledge of the target ABI, others may do. I'm thinking speci...

...ass. I could generate the assembly with -mcpu=skx but not with -mcpu=core-avx2. Could you please take a look? BTW, I am using LLVM-3.7. Best, Zhi On Wed, Jan 20, 2016 at 1:21 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > Only typo that caught my eye is ‘llvm.masked.gather.v8f64’ which should > have v2 instead of v8 to match the <2 x double> > > There's an extra comma after an "i1" too. But they both just result in > LLVM rejecting the code immediately. > > > But it still fails if I use -mcpu=core-avx2. > > My simple tests get...

On 07/02/2018 04:33 PM, Saito, Hideki wrote: > >   > > >It may not be a full solution for the problems you're trying to solve > >   > > If we are inventing a new solution, I’d like it also to solve OpenMP > declare simd legalization issue. If a small extension of existing scheme > > works for mathlib only, I’m happy to take that and discuss OpenMP >