search for: autovectorised

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

...e propagated from the parallel program. > One can then fall back to the original (hand vectorized) code in case > the autovectorization failed, to get some vector hardware utilization > still. Sounds like a nice compromise if it could be made to work. Would it be LLVM that reverts to the autovectorised version, or pocl? > On 10/25/2013 04:15 PM, Richard Sandiford wrote: >> To be honest I hadn't really thought about targets with vector units >> at all.:-) I was just assuming that we'd want to keep vector operations >> together if there's native support. E.g. IS...

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

Hello, For a while I've been working on an LLVM backend for Broadcom's VideoCore 4, the GPU made famous by the Raspberry Pi. This isn't the QPU, for which Broadcom released docs a little while ago; it's the main processor, which is a VC4 core. It's a rather elegant thing with two cores, 32 registers, a built-in DSP and an extremely nice instruction set; reverse engineered