search for: wfv

...d way of undoing compiler >> transformations. >> >> I think that a simple if-converter will be a good place to start. What >> do you think ? > > Quick comment: IIRC, Ralf Karrenberg has already implemented this (as part of his WVF project: https://github.com/karrenberg/wfv/tree/llvm_30). It might be worthwhile to work on cleaning up his implementation instead of starting from scratch. > > -Hal WFV [1] does indeed include phases that correspond to full control-flow to data-flow conversion (not just if-conversion, it can flatten all kinds of control flow inc...

...t;> > >> I think that a simple if-converter will be a good place to start. > >> What > >> do you think ? > > > > Quick comment: IIRC, Ralf Karrenberg has already implemented this > > (as part of his WVF project: > > https://github.com/karrenberg/wfv/tree/llvm_30). It might be > > worthwhile to work on cleaning up his implementation instead of > > starting from scratch. > > > > -Hal > > WFV [1] does indeed include phases that correspond to full > control-flow > to data-flow conversion (not just if-conversi...

...insics is not an OpenCL-specific limitation. Any vectorizable input suffers from that. Also, an inner loop vectorizer might be able to handle outer loops e.g. via loop interchange. I'm planning to look into that if time allows. > However, in the long run, I think the only difference between WFV-like > approaches and classic loop vectorization a la LoopVectorizer in an > OpenCL context is the following: > WFV assumes that there is at least one outer loop that has increments of > one, runs a multiple of the SIMD width iterations, and that every > iteration is independent (bar...

...ble to vectorize inner loops and (I think) does not handle function calls and memory operations well. This will prevent it from vectorizing a large group of OpenCL kernels, and certainly all "interesting", more complex ones. However, in the long run, I think the only difference between WFV-like approaches and classic loop vectorization a la LoopVectorizer in an OpenCL context is the following: WFV assumes that there is at least one outer loop that has increments of one, runs a multiple of the SIMD width iterations, and that every iteration is independent (barriers can be handled...

Hi Hal, On 10/17/12 9:43 AM, Hal Finkel wrote: >> I am currently working on a full re-implementation of the WFV >> algorithm >> on top of the latest trunk. >> One part of it that is basically finished is an analysis pass that I >> call "vectorization analysis", which annotates a function (WFV works >> on >> entire functions) with metadata used during control-flow...

> I am in favor of adding metadata to control different aspects of > vectorization, mainly for supporting user-level pargmas [1] but also for > DSLs. Before we start adding metadata to the IR we need to define the > semantics of the tags. "Parallel_for" is too general. We also want to control > vectorization factor, unroll factor, cost model, etc. These are used to

...tly don't have a good way of undoing compiler > transformations. > > I think that a simple if-converter will be a good place to start. What > do you think ? Quick comment: IIRC, Ralf Karrenberg has already implemented this (as part of his WVF project: https://github.com/karrenberg/wfv/tree/llvm_30). It might be worthwhile to work on cleaning up his implementation instead of starting from scratch. -Hal > > > I've written a dependence analyzer that ought to be suitable > > (if it isn't, we should fix it). > > I know :) Yes, this is really good. An...

...ode and wondered if there was any > current or planned effort to introduce SIMD implementations of > sin/cos/exp/log intrinsics (in particular for x86-64 backend)? Ralf Karrenberg had implemented some of these as part of his whole-function vectorization project: https://github.com/karrenberg/wfv/blob/master/src/utils/nativeSSEMathFunctions.hpp https://github.com/karrenberg/wfv/blob/master/src/utils/nativeAVXMathFunctions.hpp Opinions on pulling these into the X86 backend? -Hal > > > Cheers, > > > > > Dimitri. > __________________________________________...

...> > current or planned effort to introduce SIMD implementations of > > sin/cos/exp/log intrinsics (in particular for x86-64 backend)? > > Ralf Karrenberg had implemented some of these as part of his > whole-function vectorization project: > > https://github.com/karrenberg/wfv/blob/master/src/utils/nativeSSEMathFunctions.hpp > > https://github.com/karrenberg/wfv/blob/master/src/utils/nativeAVXMathFunctions.hpp > > Opinions on pulling these into the X86 backend? > > -Hal > > > > > > > Cheers, > > > > > > > >...

On 28/01/2013 12:49 AM, Hal Finkel wrote: > Ralf Karrenberg had implemented some of these as part of his > whole-function vectorization project: > https://github.com/karrenberg/wfv/blob/master/src/utils/nativeSSEMathFunctions.hpp > https://github.com/karrenberg/wfv/blob/master/src/utils/nativeAVXMathFunctions.hpp > Opinions on pulling these into the X86 backend? -Hal I've actually been considering doing the same as these for our project (using the same reference im...

Hi everyone, I was looking at loop vectorizer code and wondered if there was any current or planned effort to introduce SIMD implementations of sin/cos/exp/log intrinsics (in particular for x86-64 backend)? Cheers, Dimitri. -------------- next part -------------- An HTML attachment was scrubbed... URL:

...ctorizer might be able to handle outer > loops > e.g. via loop interchange. I'm planning to look into that if time > allows. This is also on my TODO list. Let's collaborate when you have time. > > > However, in the long run, I think the only difference between > > WFV-like > > approaches and classic loop vectorization a la LoopVectorizer in an > > OpenCL context is the following: > > WFV assumes that there is at least one outer loop that has > > increments of > > one, runs a multiple of the SIMD width iterations, and that every >...

..., but to my knowledge LLVM > is only able to do such a transformation in very limited and obvious cases. > We implemented phases that do a generic linearization of control flow as > part of our "whole function vectorization" algorithm: > > www.cdl.uni-saarland.de/**projects/wfv<http://www.cdl.uni-saarland.de/projects/wfv> > > The code is not really public yet because we are still working to get it > more stable and mature overall before having the entire LLVM community be > aware of it, but you can still access it at github if you want to take a > loo...

...nned effort to introduce SIMD implementations of >> > sin/cos/exp/log intrinsics (in particular for x86-64 backend)? >> >> Ralf Karrenberg had implemented some of these as part of his >> whole-function vectorization project: >> >> https://github.com/karrenberg/wfv/blob/master/src/utils/nativeSSEMathFunctions.hpp >> >> https://github.com/karrenberg/wfv/blob/master/src/utils/nativeAVXMathFunctions.hpp >> >> Opinions on pulling these into the X86 backend? >> >> -Hal >> >> > >> > >> > Cheers,...

...any > > current or planned effort to introduce SIMD implementations of > > sin/cos/exp/log intrinsics (in particular for x86-64 backend)? > > Ralf Karrenberg had implemented some of these as part of his > whole-function vectorization project: > https://github.com/karrenberg/wfv/blob/master/src/utils/nativeSSEMathFunctions.hpp > https://github.com/karrenberg/wfv/blob/master/src/utils/nativeAVXMathFunctions.hpp > > Opinions on pulling these into the X86 backend? > > -Hal > > > > > > > Cheers, > > > > > > > &gt...

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/attachments/20150706/7acac468/attachment.html>

...nt or planned effort to introduce SIMD implementations of >>> sin/cos/exp/log intrinsics (in particular for x86-64 backend)? >> >> Ralf Karrenberg had implemented some of these as part of his >> whole-function vectorization project: >> https://github.com/karrenberg/wfv/blob/master/src/utils/nativeSSEMathFunctions.hpp >> https://github.com/karrenberg/wfv/blob/master/src/utils/nativeAVXMathFunctions.hpp >> >> Opinions on pulling these into the X86 backend? >> >> -Hal >> >>> >>> >>> Cheers, >>...

...or planned effort to introduce SIMD implementations of >>> sin/cos/exp/log intrinsics (in particular for x86-64 backend)? >> >> Ralf Karrenberg had implemented some of these as part of his >> whole-function vectorization project: >> https://github.com/karrenberg/wfv/blob/master/src/utils/nativeSSEMath >> Functions.hpp >> https://github.com/karrenberg/wfv/blob/master/src/utils/nativeAVXMath >> Functions.hpp >> >> Opinions on pulling these into the X86 backend? >> >> -Hal >> >>> >>> >>...

...ntroduce SIMD implementations of > >>> sin/cos/exp/log intrinsics (in particular for x86-64 backend)? > >> > >> Ralf Karrenberg had implemented some of these as part of his > >> whole-function vectorization project: > >> https://github.com/karrenberg/wfv/blob/master/src/utils/nativeSSEMath > >> Functions.hpp > >> https://github.com/karrenberg/wfv/blob/master/src/utils/nativeAVXMath > >> Functions.hpp > >> > >> Opinions on pulling these into the X86 backend? > >> > >> -Hal > >&gt...

...rize a kernel as expected. > You need to implement something like Whole Function Vectorization > (http://dl.acm.org/citation.cfm?id=2190061). The loop vectorizer can't > help you here. Ralf Karrenberg open sourced his implementation on github. > You should take a look. I think the WFV paper has plenty of good ideas that could be applied to *improve* the vectorizability of DLP code/parallel loops (e.g. the mask generation for diverging branches where the traditional if-conversion won't do, especially intra kernel for-loops), but the actual vectorization could be modularized t...