search for: autovectorizer

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/...

On 07/07/2015 01:32 PM, Renato Golin wrote: > Wouldn't OpenMP account for some of that? At least on a single > machine, could you have both parallel and simd optimisations done on > the same loop? The point in SPMD program description (e.g. CUDA or OpenCL C) autovectorization is to produce something like OpenMP parallel loops or SIMD pragmas automatically from the single thread/WI

Hi, I started to play with the LoopVectorizer of LLVM trunk on the work-item loops produced by pocl's OpenCL C kernel compiler, in hopes of implementing multi-work-item work group autovectorization in a modular manner. The vectorizer seems to refuse to vectorize the loop if it sees multiple writes to the same memory object within the same iteration. In case of parallel loops such as the

----- 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

Hi Pekka, > Hi, > > I started to play with the LoopVectorizer of LLVM trunk > on the work-item loops produced by pocl's OpenCL C > kernel compiler, in hopes of implementing multi-work-item > work group autovectorization in a modular manner. > Thanks for checking the Loop Vectorizer, I am interested in hearing your feedback. The Loop Vectorizer does not fit here.

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 improve...