search for: autovectorize

I would like to know the status of the autovectorization support in LLVM. does LLVM have a loop dependence analysis, does LLVM have a infrastructure for autovectorization ? etc. Kind Regards Xin Tong -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110624/3dc35318/attachment.html>

On 24 June 2011 21:13, Xin Tong Utoronto <x.tong at utoronto.ca> wrote: > I would like to know the status of the autovectorization support in LLVM. >  does LLVM have a loop dependence analysis, does LLVM have a infrastructure > for autovectorization ? etc. Not yet, but it's getting there... http://polly.grosser.es/ cheers, --renato

Hi, Are there any plans to integrate an autovectorizer for SPMD programs into LLVM? For example, there were previous discussions about integrating the whole function vectorizer (WFV) from Ralf Karrenberg into LLVM. Thanks, Zack -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev...

...its barrier synchronization semantics etc. That is, the output of this pass could be also converted to OpenMP SIMD constructs, if wanted. In pocl's case the output is simply a new kernel function (we call "work group function") that executes all WIs using parallel loops (which can be autovectorized more easily, or even multithreaded if seeing fit, or both). -- --Pekka

...n of parallelism information in LLVM some time ago in this list, but it somehow died. Was adding some parallelism information to the LLVM IR decided to be a bad idea? Any conclusion in that? Another thing with OpenCL C autovectorization is that the language itself has vector datatypes. In order to autovectorize multi-WI work groups efficiently, it might be beneficial to break the vectors in the single work item to scalars to get more efficient vector hardware utilization. Is there an existing pass that breaks vectors to scalars and that works on the LLVM IR level? There seems to be such at the code gen le...

----- Original Message ----- > From: "Ralf Karrenberg" <Chareos at gmx.de> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Nadav > Rotem" <nrotem at apple.com> > Sent: Friday, February 1, 2013

Hi Hal, On 1/31/13 6:47 PM, Hal Finkel wrote: >>> In any case, since our own OpenCL driver is more of a >>> proof-of-concept >>> implementation and not very robust, I'd be willing to give it a try >>> to >>> integrate the current libWFV into pocl. This should boost >>> performance >>> quite a bit for many kernels without too much

...is implementation on github. You should take a look. > Another thing with OpenCL C autovectorization is that the > language itself has vector datatypes. Unfortunately yes. And OpenCL compilers scalarize these vector operations at some point in the compilation pipeline. > In order to autovectorize > multi-WI work groups efficiently, it might be beneficial to > break the vectors in the single work item to scalars to get more > efficient vector hardware utilization. Is there an existing pass > that breaks vectors to scalars and that works on the LLVM IR level? No. But this pass ne...

On 07/07/2015 09:30 PM, C Bergström wrote: > If you're going to "autopar" (turn a loop into a threads which run on > many cores or something) then please don't add a dependency on OMP. I wouldn't, but simply utilize the parallel loop metadata that was originally designed for this purpose. What is done with that MD is up to other passes. -- --Pekka

----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Nadav Rotem" <nrotem at apple.com> > Sent: Friday, January 25, 2013 8:14:57 AM > Subject: Re: [LLVMdev] LoopVectorizer in OpenCL

Nick Lewycky wrote: > Andreas Bolka wrote: >> Hi all, >> >> I'd like to have a first stab at a loop-based auto-vectorization pass as >> part of 2009's Google Summer of Code program. As far as I can tell from >> searching the mailing list archives, no work on such an auto-vectorizer >> seems to be currently in progress. > > Hi Andreas, >

----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Ralf Karrenberg" <Chareos at gmx.de> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, January 31, 2013 11:15:43 AM > Subject: Re: [LLVMdev] LoopVectorizer in OpenCL C work group autovectorization > > Hi

This is very interesting work. Thanks. Quick questions / comments. 1. What's the algorithm complexity? 2. Please rename -vectorize to -bb-vectorize since this is a specific kind of vectorization. 3. Have you tried non-x86 targets? Does it work? If not, what would it take to make it work? I am concerned that LLVM currently does not have a cost model for vectorization. That's necessary for

On Sat, Oct 29, 2011 at 12:30:12PM -0500, Hal Finkel wrote: > Also, when using clang, I had to pass -Dinline= on the command line: > when using -emit-llvm, clang appears not to emit code for functions > declared inline. This is a bug, but I've not yet tracked it down. http://clang.llvm.org/compatibility.html#inline Thanks, -- Peter

Hello Hal, > MultiSource/Applications/ClamAV - fails to compile shared_sha256.c with > an error: error in backend: Cannot select: 0x4fbcb40: v2i64 = > X86ISD::MOVLPD 0x4149e00, 0x418d930 [ID=596] Please report this as a PR regardless of the pass. Bugs in the backend should be fixed. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State

Hi, I see that there are two functions in your code that are O(n^2) in number of instructions of the program: getCandidatePairs and buildDepMap. I think that you could make these two functions faster if you work on some form of factored def-use chains for memory, like the VUSE/VDEFs of GCC. I was trying to find a similar representation in LLVM: isn't there already a virtual SSA

On Tue, 2011-12-20 at 13:57 -0600, Sebastian Pop wrote: > Hi, > > I see that there are two functions in your code that are O(n^2) in > number of instructions of the program: getCandidatePairs and > buildDepMap. I think that you could make these two functions faster > if you work on some form of factored def-use chains for memory, like > the VUSE/VDEFs of GCC. Thanks for the

On Thu, Jan 26, 2012 at 2:49 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Thanks! Did you compile with any non-default flags other than -mllvm > -vectorize? I used -O3 and -vectorize, no other non-default flags. Sebastian -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

Hi Renato, On 07/07/2015 10:57 PM, Renato Golin wrote: > Now, IIRC, OpenCL had a lot of trouble from getting odd-sized vector > types in IR that the middle end would not understand, especially the > vectorizers. The solution, at least as of 2 years ago, was to > serialise everything and let the CL back-end to vectorize it. Perhaps you are referring to the problem of autovectorizing

...ificant benchmark speedups, but, I have also observed some > significant slowdowns. codegen for vector constructs is not always that great in my experience. It could be that your vectorizer is doing the right thing, and it's codegen that needs to be improved. For example when I use the GCC autovectorizer I often see LLVM codegen unnecessarily scalarizing the vector code. Did you try to analyse these slowdowns? Ciao, Duncan. I would like to share my thoughts, and hopefully > get feedback, on next steps. > > 1. "Target Data" for vectorization - I think that in order to improv...