search for: autovectoriser

Hello Everyone, I've been looking at benchmarks of LLVM recently, and overall they look pretty good. Aside from things that use OpenMP or benefit from autovectorisation, Clang/LLVM and GCC seem to come fairly close, with no overall winner. But: there do seem to have been a number of performance regressions between 2.9 and 3.0: http://openbenchmarking.org/result/1110178-AR-1110173AR66

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

On Nov 14, 2011, at 10:46 AM, David Chisnall wrote: > Hello Everyone, > > I've been looking at benchmarks of LLVM recently, and overall they look pretty good. Aside from things that use OpenMP or benefit from autovectorisation, Clang/LLVM and GCC seem to come fairly close, with no overall winner. Nice. Thanks. > > But: there do seem to have been a number of performance

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

Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> writes: > E.g., the last time I checked, the inner loop vectorizer (which pocl exploits) > just refused to vectorize loops with vector instructions. It might not > be so drastic with the SLP or the BB vectorizer, but in general, it might > make sense to let the vectorizer to do the decisions on how to map the > parallel

Hi, I found out that Auto-Vectorization was implemented as a part of GSoC 2009. Can someone point me to the code repository including any documentation available? I would also like to know if there is any progress/future plans to include this in the main trunk? Best Regards, Raj

Hi, Great to see someone working on this. This will benefit the performance portability goal of the pocl's OpenCL kernel compiler. It has been one of the low hanging fruits in improving its implicit WG vectorization applicability. The use case there is that sometimes it makes sense to devectorize the explicitly used vector datatype code of OpenCL kernels in order to make better opportunities

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

Le 14 novembre 2011 20:40, Evan Cheng <evan.cheng at apple.com> a écrit : > > On Nov 14, 2011, at 10:46 AM, David Chisnall wrote: > > > Hello Everyone, > > > > I've been looking at benchmarks of LLVM recently, and overall they look > pretty good. Aside from things that use OpenMP or benefit from > autovectorisation, Clang/LLVM and GCC seem to come

...e things it does --- 32 bit integer and float, most ALU operations, some memory operations. It doesn't know about instruction displacements yet so the generated code probably won't assemble, and it doesn't know about 64 bit integers yet, which means it gets on very badly with LLVM's autovectoriser. I was eventually hoping that it would be useful to run programs on the Raspberry Pi bare metal; I've had success with this using an extremely crude VC4 code generator for the ACK, but the generated code was painfully terrible, hence this port. Unfortunately I've run out of time and proba...