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 area for fruitful work both algorithmically and in terms of practical relevance, it'd also be interesting to see what LLVM complied from languages with semantics that are more open to optimization can do to indicate these things to the auto-vectorizer. (I have my own personal after-hours OSS project that will soon be generating LLVM IR for which vectorization will be important. I don't want to implement vectorization myself before generating LLVM IR, partly since hopefully the LLVM layer will have a much better estimate of the costs/benefits, so having some written metadata I can set to indicate various things the vectorizer would otherwise deduce (non-aliasing, loop-permutability, etc) would be very interesting.) Regards, Dave Tweed -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121106/f51edca2/attachment.html>
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 area for fruitful work both algorithmically and in terms of practical relevance, it'd also be interesting to see what LLVM complied from languages with semantics that are more open to optimization can do to indicate these things to the auto-vectorizer. (I have my own personal after-hours OSS project that will soon be generating LLVM IR for which vectorization will be important. I don't want to implement vectorization myself before generating LLVM IR, partly since hopefully the LLVM layer will have a much better estimate of the costs/benefits, so having some written metadata I can set to indicate various things the vectorizer would otherwise deduce (non-aliasing, loop-permutability, etc) would be very inter!esting.) This is definitely something that we plan to do. We would like to be able to annotate loops (using metadata or special intrinsics, etc) and to indicate that they are vectorizable. This is something that domain specific languages can use. This will also allow us to improve vectorization of C-based languages because the user will be able to tell the compiler that a loop is safe to vectorize. The Intel compiler already supports vectorizer pragmas to specify which loop should be vectorized and to what vectorization factor. I don't plan to start working vectorization hints soon, but this is one of the items on the vectorizer TODO list that I am going to present at the BoF. Nadav> > Regards, > Dave Tweed >
----- 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 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 area for fruitful work both algorithmically and in > > terms of practical relevance, it'd also be interesting to see what > > LLVM complied from languages with semantics that are more open to > > optimization can do to indicate these things to the > > auto-vectorizer. (I have my own personal after-hours OSS project > > that will soon be generating LLVM IR for which vectorization will > > be important. I don't want to implement vectorization myself > > before generating LLVM IR, partly since hopefully the LLVM layer > > will have a much better estimate of the costs/benefits, so having > > some written metadata I can set to indicate various things the > > vectorizer would otherwise deduce (non-aliasing, > > loop-permutability, etc) would be very inter! > esting.) > > This is definitely something that we plan to do. We would like to be > able to annotate loops (using metadata or special intrinsics, etc) > and to indicate that they are vectorizable. This is something that > domain specific languages can use. This will also allow us to > improve vectorization of C-based languages because the user will be > able to tell the compiler that a loop is safe to vectorize. The > Intel compiler already supports vectorizer pragmas to specify which > loop should be vectorized and to what vectorization factor. I don't > plan to start working vectorization hints soon, but this is one of > the items on the vectorizer TODO list that I am going to present at > the BoF.I'd like to add: Please develop a wish list of such things, and, if possible, patches. Thanks again, Hal> > Nadav > > > > > Regards, > > Dave Tweed > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory