search for: autopar

...(can exist without OpenMP support in fact). Thanks Regards Prakash -----Original Message----- From: Tobias Grosser [mailto:tobias at grosser.es] Sent: Wednesday, July 04, 2012 9:27 PM To: Raghavendra, Prakash Cc: llvmdev at cs.uiuc.edu; preston.briggs at gmail.com Subject: Re: [LLVMdev] OpenMP/autopar support in LLVM On 07/04/2012 10:35 AM, Raghavendra, Prakash wrote: > Hi > > I wanted to know the status of OpenMP (or in general auto > parallelization) support in > > LLVM. > > I read some threads discussing about possible effort in that direction > in 3.1 onwards, &g...

On 07/04/2012 10:35 AM, Raghavendra, Prakash wrote: > Hi > > I wanted to know the status of OpenMP (or in general auto > parallelization) support in > > LLVM. > > I read some threads discussing about possible effort in that direction > in 3.1 onwards, > > but did not see any further discussion on that. > > If someone in the list knows the updated info or can

Hi I wanted to know the status of OpenMP (or in general auto parallelization) support in LLVM. I read some threads discussing about possible effort in that direction in 3.1 onwards, but did not see any further discussion on that. If someone in the list knows the updated info or can point me to any useful info, that would be useful. Thanks Regards Prakash Raghavendra -------------- next part

...code, and provides necessary parallelism information (These information could be encoded as metadata just like TBAA), then the later passes can generate the parallel code with those parallelism information. The main benefit of separating transform passes and codegen passes are: 1. Decouple the the autopar framework from various parallel runtime environment, so we can keep both autopar framework and code generation pass for specific parallel runtime environment simple. And we can support more parallel runtime environments easily. 2. Allow the some generic parallelism information live out specific au...

Hello, Erwin > Although most of this is plain portable C++ perhaps LLVM can auto-vectorize > some of this? Well, I doubt so, unfortunately - LLVM does not have any autopar these days > There is a little bit of hand optimized x86 SSE code. This is only enabled > on 32bit Windows and Mac OSX Intel builds. Ok. What's about Linux builds? Are there any other implementations e.g. altivec / NEON ? > You could take Bullet/Demos/Benchmarks as a starting point,...

...se information could be encoded > as metadata just like TBAA), then the later passes can generate the > parallel code with those parallelism information. I also thought about this approach. > The main benefit of separating transform passes and codegen passes are: > 1. Decouple the the autopar framework from various parallel runtime > environment, so we can keep both autopar framework and code generation > pass for specific parallel runtime environment simple. And we can > support more parallel runtime environments easily. Yes, as soon as we start to support more targets we sho...

Hi Alexandra, On Thu, Sep 8, 2011 at 13:53, Jimborean Alexandra <xinfinity_a at yahoo.com> wrote: > I had a look at the CodeGeneration from Polly. Is it possible to use it > without creating the Scops, by transforming it into a LoopPass? Yes. If you don't want to use the autopar of Polly and just rely on the pragmas inserted by the programmer, you don't need SCoPs. You can have the parallel code generation part of Polly working as a LoopPass. If you want to use the auto-parallelization part of Polly, you have to to restrict the form of the code on which data dependenc...

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 want to execute the iterations of a loop in parallel, by inserting calls either to pthreads or to the gomp library at the LLVM IR level. As a first step, I inserted an omp pragma in a C file and compiled it with llvm-gcc to check the generated LLVM code. If I understand correctly, to parallelize the loop in LLVM IR, I have to separate the loop in a new function, put all required parameters

Hi Anton, Thanks a lot for offering help. Bullet uses basic linear algebra with 4-way vectors, quaternion and matrices. Although most of this is plain portable C++ perhaps LLVM can auto-vectorize some of this? There is a little bit of hand optimized x86 SSE code. This is only enabled on 32bit Windows and Mac OSX Intel builds. >> Should I just use the 2.75 release? If you are interested,

...com/y9gv3e8 Thanks, Erwin 2009/12/15 Anton Korobeynikov <anton at korobeynikov.info> > > Hello, Erwin > > > Although most of this is plain portable C++ perhaps LLVM can auto-vectorize > > some of this? > Well, I doubt so, unfortunately - LLVM does not have any autopar these days > > > There is a little bit of hand optimized x86 SSE code. This is only enabled > > on 32bit Windows and Mac OSX Intel builds. > Ok. What's about Linux builds? Are there any other implementations > e.g. altivec / NEON ? > > > You could take Bullet/Demos...

Hi tobi, >> 2. Allow the some generic parallelism information live out specific >> autopar framework, so these information can benefit more passes in >> llvm. For example, the X86 and PTX backend could use these information >> to perform target specific auto-vectorization. > > What other types of parallelism are you expecting? We currently support > thread level para...

Hi Alexandra, I don't know much, maybe this topic should be bridged with polly-dev (adding it to CC) to bring it more attention. Indeed, polly uses ScopPass, that creates serious limitations in compatibility with other passes. To my understanding, scops are used because ISL loop analysis tool uses scops. In fact, just for handling OpenMP directives scops are not required, unless one need to

...; > On Thu, Sep 8, 2011 at 13:53, Jimborean Alexandra<xinfinity_a at yahoo.com> wrote: >> I had a look at the CodeGeneration from Polly. Is it possible to use it >> without creating the Scops, by transforming it into a LoopPass? > > Yes. If you don't want to use the autopar of Polly and just rely on > the pragmas inserted by the programmer, you don't need SCoPs. > You can have the parallel code generation part of Polly working as > a LoopPass. Are you sure about this? In CodeGeneration we basically translate a CLooG AST into LLVM-IR. Without a CLooG AST...

...> > 2009/12/15 Anton Korobeynikov <anton at korobeynikov.info> >> >> Hello, Erwin >> >>> Although most of this is plain portable C++ perhaps LLVM can auto-vectorize >>> some of this? >> Well, I doubt so, unfortunately - LLVM does not have any autopar these days >> >>> There is a little bit of hand optimized x86 SSE code. This is only enabled >>> on 32bit Windows and Mac OSX Intel builds. >> Ok. What's about Linux builds? Are there any other implementations >> e.g. altivec / NEON ? >> >>>...

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

...> On Thu, Sep 8, 2011 at 13:53, Jimborean Alexandra<xinfinity_a at yahoo.com>  wrote: >> I had a look at the CodeGeneration from Polly. Is it possible to use it >> without creating the Scops, by transforming it into a LoopPass? > > Yes.  If you don't want to use the autopar of Polly and just rely on > the pragmas inserted by the programmer, you don't need SCoPs. > You can have the parallel code generation part of Polly working as > a LoopPass. Are you sure about this? In CodeGeneration we basically translate a CLooG AST into LLVM-IR. Without a CLooG AST t...

On 12 July 2013 15:49, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, There: > > This is the proposal for parallelizing post-ipo stage. See the following > for details. > > I also attach a toy-grade rudimentary implementation. This > implementation can be > used to illustrate some concepts here. This patch is not going to be > committed. > >

Hi, There: This is the proposal for parallelizing post-ipo stage. See the following for details. I also attach a toy-grade rudimentary implementation. This implementation can be used to illustrate some concepts here. This patch is not going to be committed. Unfortunately, this weekend I will be too busy to read emails. Please do not construe delayed response as being rude :-).