search for: vectoriser

Dear Guru's My first steps with R have ground to a halt! I have a vector of sample identifiers > sampleIDs [1] "D1_1" "D1_2" "D1_3" "D1_4" "D1_5" "D1_6" "D1_7" "D1_8" [9] "D1_9" "D1_10" "D1_11" "D1_12" "F1_13" "F1_14"

I have matrix multiplication and stencil code. I vectorise it through the following command. opt -S -O3 -force-vector-width=2048 stencil.ll -o stencil_o3.ll in both the examples of matrix mult and stencil it vectorises fine when my loop iterations >2048. but if i keep both iterations and vector width=2048. it produces scalar code IR not vectorizes it. Is it llvm bug? Please help me.

Yes, it looks like passing ‘EnableVec’ and ‘EnableSLPVec’ to ‘Args.hasFlag’ should be replaced with ‘false’ and then it has the expected behaviour. MartinO From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Martin J. O'Riordan via cfe-dev Sent: 01 March 2018 18:02 To: 'Richard Smith' <richard at metafoo.co.uk> Cc: 'Clang Dev'

Dear all, is there any function to calculate the center of a polygon mass in R? Actually I need to find the best location within polygons to place labels. Thanks for any hint Jens Oehlschl?gel -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test\ --------...{{dropped}}

Hi, I have been analyzing the LLVM vectorizer by running some benchmarks. For vectorization, I have used the following flags: -O3 -ffast-math -mavx2 Am I missing any other flags which will improve vectorizer performance? Thanks, Santanu Das IIT Hyd -------------- next part -------------- An HTML attachment was scrubbed... URL:

Please ignore this thread - I got myself confused, the code is fine - too many long days and nights staring at code. There is an issue, but it is different to what I thought. My command line is not: clang -S -O3 -fno-vectorize -fno-slp-vectorize foo.c but: clang -S -fno-vectorize -fno-slp-vectorize -O3 foo.c The difference was subtly hidden in a much longer argument list

...tion/Loop, and pass those to the Transformation pass as >> part of Analysis's internal data? We've been operating under the assumption that such Analysis pass behavior is unacceptable. > > Hi Saito, > > First let me say, impressive work you guys are planning for the > vectoriser. Outer loop vectorisation is not an easy task, so feel free > to share your ideas early and often, as that would probably mean a lot > less work for you guys, too. > > Regarding generation of dead code, I don't remember any pass doing > this (though I haven't looked at many)...

No, I’m wrong. I think that bug is actually in ‘hasFlag’ itself. In ‘llvm/lib/Option/ArgList.cpp’ line #70: bool ArgList::hasFlag(OptSpecifier Pos, OptSpecifier PosAlias, OptSpecifier Neg, bool Default) const { if (Arg *A = getLastArg(Pos, PosAlias, Neg)) return A->getOption().matches(Pos) || A->getOption().matches(PosAlias); return

Hello, We are working on predication for our vector extension (MVE). Since quite a few people are working on predication and different forms of it (e.g. SVE, RISC-V, NEC), I thought I would share what we would like to add to the loop vectoriser. Hopefully it's just a minor one and not intrusive, but could be interesting and useful for others, and feedback on this is welcome of course. TL;DR: We would like the loop vectoriser to emit a new IR intrinsic for certain loops: void @llvm.set.loop.elements.i32(i32 ) This represents the...

Hi, people. Allow me to chat a tiny bit on two vectorisation-related matters, in the context of R. I'm curious about if the following ideas have ever been considered, and rejected already. First is about using the so-called Duff's device for partially unrolling loops. I did not overly check in R sources, and am not familiar with them anyway, but the only usage I saw is within

Hi All, is there any chance of vectorising the two ifelse() statements in the following code: for(i in gp){ new[i,1] = ifelse(srow[i]>0, new[srow[i],zippo[i]], sample(1:100, 1, prob =Y1, rep = T)) new[i,2] = ifelse(drow[i]>0, new[drow[i]>0,zappo[i]], sample(1:100, 1, prob =Y1, rep = T)) } Where I am forced to check if the value of drow and srow are >0 for each line... in

Xinmin, > Tom, your understanding is correct per OpenMP SIMD model. Our implementation behaves as you stated. > Which is not part of LLVM main trunk yet. Is that the implementation that is based on the intrinsics in the RFC you and Hal Finkel had sent out to the list? Or is it a different implementation (and if so, is there some plan to merge the two)? Thanks, --Vikram Adve //

Hello, Quick question to see if I haven't missed anything: I would like convert counting down loops, i.e. loops with a constant -1 step value, to counting up loops, because the vectoriser is able to better deal with these loops (see e.g. D76838 that I was discussing today with Ayal). It looks like LoopSimplifyCFG and IndVarSimplify don't do this. So was just curious if I haven't missed anything here or in another pass I haven't yet considered. I was perhaps also expectin...

...much for compilers to pass. If I create a vectorised loop that goes all the way to 92, I'll have to create a tail loop. If I don't want to create a tail loop, I have to override 'b' (and probably 'c') on a vector write. If I implement the variations where I can do that, the vectoriser will be very happy. People generally like when the vectoriser is happy. Now, you have a "safe mode" where these things don't happen. Let's say you and me agree that it should only go to 95, since this is "probably what the user wants". But some programmers *use* that as...

Hi R guru coders I wrote a bit of code to add a new column onto a "topTable" dataframe. That is a list of genes processed using the limma package. I used a for loop but I kept feeling there was a better way using a more vector oriented approach. I looked at several commands such as "apply", "by" etc but could not find a good way to do it. I have this feeling there

...uck are probably the code generator and auto-vectorization. > Increasing the number of developers would be helpful. I'm not a GCC expert, but their auto-vectorization is not that great. It may be simple to do basic loop transformations and some stupid vectorization, but having a really good vectoriser is a lot of work. I personally think that the biggest difference is the number of people that have contributed over the years on very specific optimizations. There are as many corner cases as there are particles in the universe (maybe more), and implementing each one of them requires time and peop...

>From: Sundar Dorai-Raj <sundar.dorai-raj at PDF.COM> >Reply-To: sundar.dorai-raj at PDF.COM >To: Zhen Pang <nusbj at hotmail.com> >CC: r-help at stat.math.ethz.ch >Subject: Vectorising and loop (was Re: [R] optim "a log-likelihood >function") >Date: Wed, 29 Sep 2004 18:21:17 -0700 > > > >Zhen Pang wrote: > >> >>I also use

Hi, Gerolf. We've been a bit quiet for some time. After listening to feedback on the project internally and externally, we decided to take a more generally accepted community development model ---- building up through a collection of small incremental changes ---- than trying to make a big step forward. That change of course took a bit of time, but we are getting close to the first NFC patch

...ed.load/store instructions in the loop. This is what we are currently doing and works excellent for simpler cases. For the more complicated cases that we now what to handle as well, the pattern matching just becomes a bit too horrible, and it is fragile too. All we need is the information that the vectoriser already has, and pass this on somehow. As I am really keen to simply our backend pass, would there be another way to pass this information on? If emitting an intrinsic is a blocker, could this be done with a loop annotation? Cheers, Sjoerd. ________________________________ From: Eli Friedman <...

...xity in the back-end to match long patterns for >>> complexity in optimisation passes to know about the new intrinsics. >>> >>> The arguments were: >>> >>> Pro intrinsic: >>> * Simpler and shorter IR >>> * Easier to read, easier for the vectorisers to generate >>> * Easier for the back-end to match >>> * Easier transition towards scalable vectors in the future >> Also want to re-iterate that reductions are useful for testing bits of >> predicate vectors, which can be applicable to other targets than SVE >>...