similar to: [LLVMdev] Regarding BOF: Vectorization in LLVM

Hi David! On Nov 6, 2012, at 3:23 AM, David Tweed <david.tweed at gmail.com> wrote: > Hi Nadav, > > Unfortunately I'm not attending the dev meeting, but the BoF looks interesting. One thing that I'd like to throw into the mix is that, while dealing with autovectorisation of LLVM compiled down from C-like languages (or maybe Fortran-like languages) is clearly a very big

----- Original Message ----- > From: "Nadav Rotem" <nrotem at apple.com> > To: "David Tweed" <david.tweed at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Tuesday, November 6, 2012 11:08:23 AM > Subject: Re: [LLVMdev] Regarding BOF: Vectorization in LLVM > > Hi David! > > On Nov 6, 2012, at 3:23 AM, David Tweed <david.tweed at

On Tue, Nov 6, 2012 at 6:11 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Nadav Rotem" <nrotem at apple.com> >> To: "David Tweed" <david.tweed at gmail.com> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Tuesday, November 6, 2012 11:08:23 AM >> Subject: Re: [LLVMdev] Regarding BOF: Vectorization in

On Nov 6, 2012, at 10:45 AM, David Tweed <david.tweed at gmail.com> wrote: > I'll certainly try to do this, although I suspect it's going to be > more of a matter of mutual interaction from both ends: > > * DSL developers: I could tell you these things: ...., can you > profitably use them? > * Autovectorizer developers: I can make use of these things: ...., are

On 10/08/2012 06:02 AM, Nadav Rotem wrote: > Hi Javed, > > Developing a good loop vectorizer takes several years. The work on the GCC vectorizer began in 2004, and they spent several years improving and optimizing their vectorizer. They started by vectorizing simple loops, and added features that they needed in order to vectorize additional loops that were important for them. They

Hi, I would like to start a discussion about enabling the loop vectorizer by default for -Os. The loop vectorizer can accelerate many workloads and enabling it for -Os and -O2 has obvious performance benefits. At the same time the loop vectorizer can increase the code size because of two reasons. First, to vectorize some loops we have to keep the original loop around in order to handle the last

Hi Javed, Developing a good loop vectorizer takes several years. The work on the GCC vectorizer began in 2004, and they spent several years improving and optimizing their vectorizer. They started by vectorizing simple loops, and added features that they needed in order to vectorize additional loops that were important for them. They started with a single-block loops, and later they added

Hi, Thanks for the feedback. I think that we agree that vectorization on -Os can benefit many programs. Regarding -O2 vs -O3, maybe we should set a higher cost threshold for O2 to increase the likelihood of improving the performance ? We have very few regressions on -O3 as is and with better cost models I believe that we can bring them close to zero, so I am not sure if it can help that much.

Hi Nadav (and others who are related to this issue) - I saw some discussions on loop vectorizer that you are planning to write. Do you foresee using Polyhedral Framework (polly project) in some way in that. Thanks J. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121007/476abc1c/attachment.html>

On Oct 7, 2012, at 11:53 PM, Tobias Grosser <tobias at grosser.es> wrote: > As the design of the vectorizer is a very hot topic, I was wondering if there will be a BoF session on the LLVM conference? Nadav, you have not proposed one by accident? I proposed a BoF, and (if accepted) we can start discussing the design of the llvm loop vectorizer and the infrastructure that we need for

Dear community, We are trying to setup a BoF ( Raising Next Generation of LLVM Developers, http://sched.co/8Yzs). In our academic-oriented environments the main work force is students: undergrads, grads or PhD (rarely postdocs). Often we have limited time to bring somebody up to speed and we have to it in a productive and motivating for both parties way. I believe most of you had

Hi, We are going to have a BoF session on vectorization on Nov 8th. Everybody is invited! Most of the BoF is going to be an open discussion, but Hal and I are also going to talk a little bit about the Loop vectorizer, the BB vectorizer and the common infrastructure. Here is a preliminary agenda for the BoF: 1. A quick overview on vectorization in LLVM - 3 min. 2. Loop vectorizer design

Hi Nadav/Devs I am exploring Loop Vectorizer to vectorize i8 scalar operations into 8xi8 vector operation. I was expecting the Loop Vectorizer to analyze the profitability for vectorization factor(VF) of 8, However it is not doing so due to the widest type calculation done for the blocks inside the loop. May be I am missing something, however, I am curious to know why Loop Vectorizer limits the

So IMO, if we modify the VF calculation for targets/subtargets using TTI where higher VF is supported The vectorizer’s scope will become wider. Did/do you foresee any issue with this? Thanks, Shahid From: Nadav Rotem [mailto:nrotem at apple.com] Sent: Saturday, December 13, 2014 2:47 AM To: Shahid, Asghar-ahmad Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Vectorization factor limitation in

Nadav, Arnold, et al., I have a number of loops that I would like us to be able to autovectorize (common, for example, in n-body inter-particle force kernels), and the problem is that they look like this: for (int i = 0; i < N; ++i) { if (r[i] > 0) v += m[i]*...; } where, as written, m[i] is not accessed unless the condition is true. The general problem (as is noted by the loop

All, I have arranged for an LLVM BoF at SC13 in Denver: http://sc13.supercomputing.org/schedule/event_detail.php?evid=bof143 If you will be at SC13, have an interesting project based on or within LLVM, and would be willing to come to the BoF and spend 10 minutes or so giving an overview of it, please email me. I am trying to get a collection of people together to talk about vectorization and

> > I'm not. :( > I think that this is probably the most important feature for the vectorizer right now. Other features require adding complexity to the vectorizer while this feature is relatively simple. > What kind of pragmas would work for this loop? Something telling that it's safe to speculatively read from m[] at any position? In this reduction case it might be

This is almost ideal for SLP vectorization, except for two problems: 1. We have 4 stores to consecutive locations, but the last element is the constant zero, and not an additional SUB. At the moment we don’t have support for idempotence operations, but this is something that we should add. 2. The values that we are subtracting come from 3 loads. We usually load 4 elements from memory, or

Hi Vesa, The pass IndVars changes the induction variables to allow SCEV to analyze them and enable other optimizations. This is the canonicalization phase. Later on, LSR lowers the canonicalized induction variables to induction variables that map nicely to the target's addressing modes. In many cases it can remove some of the induction variables. I suspect that the loop vectorizer does

Hi Nadav, Arnold, (now copying LLVM-dev, not commits), I'm working on an example of a code that current GCC trunk can vectorize but LLVM cannot, and after analysing the intermediate IR just before the loop vectorization and by stepping through the process, I can see that the vectorizer only recognizes integer and float reduction variables, not pointers. My code looks like this: for (i: 0