similar to: [LLVMdev] Vectorization metadata

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

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

On Wed, 18 Apr 2012 17:30:11 +0100 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. ;) Fair enough, but I was actually taking about how fp-math, etc. metadata is updated during vectorization. When vectorization fuses originally-independent instructions, it has the

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. I have some idea to improve the current auto-vectorization and parallelization approach in Polly. 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

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

On Wed, 18 Apr 2012 20:17:35 +0100 Renato Golin <rengolin at systemcall.org> wrote: > 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

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

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

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

** *Hi everyone,As you may know, stock LLVM does not provide the kind of advanced loop transformations necessary to provide good performance on many applications. LLVM's Polly project provides many of the required capabilities, including loop transformations such as fission, fusion, skewing, blocking/tiling, and interchange, all powered by state-of-the-art dependence analysis. Polly also

On Mon, Feb 6, 2012 at 12:13 PM, Sebastian Pop <spop at codeaurora.org> wrote: > [many things, but I'm only going to focus on one of them] > Would you consider using Polly http://polly.grosser.es to avoid > writing this code? My impression is that Polly (and polyhedral analysis generally) doesn't do want I want. But I'm happy to talk about it 'cause I might be

On 02/06/2012 10:02 PM, Preston Briggs wrote: > On Mon, Feb 6, 2012 at 12:13 PM, Sebastian Pop <spop at codeaurora.org > <mailto:spop at codeaurora.org>> wrote: >> [many things, but I'm only going to focus on one of them] Would >> you consider using Polly http://polly.grosser.es to avoid writing >> this code? > > My impression is that Polly (and

On Sat, Feb 4, 2012 at 2:27 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Fri, 2012-02-03 at 20:59 -0800, Preston Briggs wrote: >> so are building a dependence graph for a complete function.  Of >> course, such a thing is useful for vectorization and all sorts of >> other dependence-based loop transforms. >> >> I'm looking at the problem in two parts:

>> for (unsigned i = 0; i < buckets; i++) >>  count[i] = 0; >> >> for (unsigned i = 0; i < n; i++) >>   count[src[i]]++; >> >> start[0] = 0; >> for (unsigned i = 1; i < buckets; i++) >>   start[i] = start[i - 1] + count[i - 1]; >> >> #pragma assert parallel >> for (unsigned i = 0; i < n; i++) { >>   unsigned

Hi Hal, Tobias, Michael, and others, I'd like to add my view (and a proposal) to this discussion and I apologize directly for doing this so late*. I also want to apologize because this email is long, contains various technical details and also argumentations that might need more justification. However, I am happy to provide further information (and/or examples) to explain my views if

Dear LLVM contributors, my name is Matthias, I am a graduate student majoring in computer science at the Vienna University of Technology, and I am glad to be one of this year's GSoC students who work for the Julia foundation. Julia is a relatively young programming language that uses LLVM for just-in-time compilation and the goal of my project is to integrate Polly in this environment to

Hi, Johannes, Thanks for writing this. I certainly think you have the right idea in terms of the desired end state and modular design. On 09/19/2017 07:33 PM, Johannes Doerfert wrote: > Hi Hal, Tobias, Michael, and others, > > I'd like to add my view (and a proposal) to this discussion and I > apologize directly for doing this so late*. I also want to apologize > because this

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

On Nov 6, 2012, at 10:45 AM, David Tweed <david.tweed at gmail.com> wrote: > I'll certainly try to do this, although I suspect it's going to be > more of a matter of mutual interaction from both ends: > > * DSL developers: I could tell you these things: ...., can you > profitably use them? > * Autovectorizer developers: I can make use of these things: ...., are