similar to: [LLVMdev] Proposal: Generic auto-vectorization and parallelization approach for LLVM and Polly

On 01/06/2011 03:38 AM, ether zhhb wrote: > Hi, > > I just have a detail look at the code of Polly[1], it seems that Polly > start to support some basic auto-parallelization stuffs. This is true. However still work in progress. I hope we can soon show some interesting results. > I have some idea to improve the current auto-vectorization > and parallelization approach in

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

On 6 January 2011 15:16, Tobias Grosser <grosser at fim.uni-passau.de> wrote: >> The main idea is, we separate the transform passes and codegen passes >> for auto-parallelization and vectorization (Graphite[2] for gcc seems >> to taking similar approach for auto-vectorization). I agree with Ether. A two-stage vectorization would allow you to use the simple loop-unroller

On 09/12/2011 04:28 PM, Sebastian Pop wrote: > 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

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

On 01/06/2011 10:59 AM, Renato Golin wrote: > On 6 January 2011 15:16, Tobias Grosser<grosser at fim.uni-passau.de> wrote: >>> The main idea is, we separate the transform passes and codegen passes >>> for auto-parallelization and vectorization (Graphite[2] for gcc seems >>> to taking similar approach for auto-vectorization). > > I agree with Ether. >

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 9 January 2011 00:07, Tobias Grosser <grosser at fim.uni-passau.de> wrote: > Matching the target vector width in our heuristics will obviously give the > best performance. So to get optimal performance Polly needs to take target > data into account. Indeed! And even if you lack target information, you won't generate wrong code. ;) > Talking about OpenCL. The lowering

On 01/08/2011 07:34 PM, Renato Golin wrote: > On 9 January 2011 00:07, Tobias Grosser<grosser at fim.uni-passau.de> wrote: >> Matching the target vector width in our heuristics will obviously give the >> best performance. So to get optimal performance Polly needs to take target >> data into account. > > Indeed! And even if you lack target information, you

Hi Ether, On 18 April 2012 19:11, Hongbin Zheng <etherzhhb at gmail.com> wrote: > Instead of exporting the polyhedral model of the program with > metadata, another possible solution is designing a generic "Loop > Parallelism" analysis interface just like the AliasAnalysis group. > For a particular loop, the interface simply answer how many loop > iterations can run

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

On 8 January 2011 18:27, Tobias Grosser <grosser at fim.uni-passau.de> wrote: > OK. First of all to agree on a name, we decided to call the Polyhedral > analysis we develop PoLLy, as in Polly the parrot. ;-) Maybe it was a > misleading choice? I never realised... ;) Polly it is! > In general as I explained I agree that a three stage approach is useful, > for the reasons you

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

Hal, I'm opening a new discussion on vectorization metadata, since it has little to do with fp-math. ;) What kind of metadata would you annotate in the instructions? If I remember from your talk, you're not doing any loop or whole-function analysis, possibly leaving it for Polly to help you along the way. I remember discussing it with Tobias that Polly could have three main steps: 1.

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

On Thu, Apr 19, 2012 at 12:30 AM, Renato Golin <rengolin at systemcall.org> wrote: > Hal, > > I'm opening a new discussion on vectorization metadata, since it has > little to do with fp-math. ;) > > What kind of metadata would you annotate in the instructions? If I > remember from your talk, you're not doing any loop or whole-function > analysis, possibly

Thanks for your ideas. Polly looked interesting as it seems it has already introduced the basic support for OpenMP that I need. But indeed, it seems difficult to apply the same code on a regular LLVM loop, instead of a SCoP. What I am working on is speculative parallelism, so I cannot provide the SCoPs required by Polly. I analyze the loops and try to parallelize them speculatively at the LLVM

On 6 May 2010 05:34, Chris Lattner <clattner at apple.com> wrote: > On May 5, 2010, at 1:01 PM, Rajkishore Barik wrote: >> I would also like to know if there is any progress/future plans to >> include this >> in the main trunk? > > Unfortunately, nothing came of this project AFAIK, maybe Devang knows more. I looked for it and couldn't find any, too. I found

On 01/08/2011 06:52 PM, Renato Golin wrote: > On 8 January 2011 18:27, Tobias Grosser<grosser at fim.uni-passau.de> wrote: >> OK. First of all to agree on a name, we decided to call the Polyhedral >> analysis we develop PoLLy, as in Polly the parrot. ;-) Maybe it was a >> misleading choice? > > I never realised... ;) Polly it is! > > >> In general as I

Hi ether, On 12/26/09 13:06, ether zhhb wrote: > hi, > > dose anyone going/planning to add something like > Graphite(http://gcc.gnu.org/wiki/Graphite) in gcc to llvm(or that > should be implement at the level of clang?)? I already looked into implementing something like Graphite for LLVM. However just recently, so I have not released any code yet. As soon as some code is