similar to: [LLVMdev] "Graphite" for llvm [building infrastructure]

On 01/05/10 14:45, ether wrote: > hi Tobi, > > i just added the Poly > library(http://wiki.llvm.org/Polyhedral_optimization_framework) to llvm > build system, which only contain a toy pass "Poly". > i think we could add the polyhedral optimization stuff in to this library. > > it was test under cmake+visual studio 2009, and i also add the library > build rule

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

Hi all, I would like to participate in Google's Summer of Code this year, for LLVM(Polly), The polyhedral optimization framework ( http://wiki.llvm.org/Polyhedral_optimization_framework ) which i am already working on with Tobias. Polly is a polyhedral optimization framework for llvm, which similar to Graphite for gcc (http://gcc.gnu.org/wiki/Graphite). The main work flow of Polly is:

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 12/27/09 10:18, ether wrote: > hi Tobi , > > that sounds greate :D > > On 2009-12-27 5:43, Tobias Grosser wrote: >> 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 available I will post patches. > whats its status? do you need any help? Very

hi Tobi , that sounds greate :D On 2009-12-27 5:43, Tobias Grosser wrote: > 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 available I will post patches. whats its status? do you need any help? > A general plan to implement polyhedral transformations in LLVM: > > 1.

Hi Javed, On 06/18/10 14:07, Javed Absar wrote: > Hi: > I worked on loop-optimizations techniques previously using ORC. > Currently i see lots of research on speculative parallelization of > loops ... specially because multicores [for embedded systems] is > becoming popular. In other words, because you have > multiple cores, you can start some loops [Fast-Track] as if there 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 Tobias: Thanks for replying . So if I understand correctly, in LLVM currently, the Polyhedral model is being built ( LLVM IR -------> Poly Model ----------> LLVM IR ). This is for compile-time optimizations of loop-nests [e.g. loop-transformations to expose parallelism or improve locality etc]. Yes, thats great for optimizing loop-nests. As an additional, since the real value of LLVM

On 05/06/10 10:40, Renato Golin wrote: > 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

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

ether wrote: >> The polyhedral loop description is simple and not compiler depended. >> Therefore external tools like LooPo (automatic parallelization), Pluto >> (optimization in general) > i had contacted the author a week ago, and if we use it, we need a IR > generator in llvm side to extract SCoP, and the corresponding parser in > Pluto side that read, then a

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

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

Tobias Grosser wrote: > The way to go is the scoplib format (propably extended by quantified > variables). This format could be extracted from graphite easily and > could also be created in LLVM. > What we need to get back into LLVM is only the new optimized schedule > described e.g. as cloog like scattering functions. These can be parsed > easily. The real code generation

hi all, The patch in the attachment add a new pass - region pass to the llvm system. A region pass is similar to a loop pass, all of them execute on a group of BasicBlocks at one time, but it operate on a single entry single exit region, not the nature loop. The original purpose to add such a pass to llvm system is to allow us find out the static control part (SCoP) for the polyhedral

On Wed, Sep 13, 2017 at 8:05 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 09/13/2017 06:53 AM, C Bergström wrote: > > > > On Wed, Sep 13, 2017 at 7:43 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> On 09/13/2017 02:16 AM, C Bergström wrote: >> >> A completely non-technical point, but what's the current "polly"

hi, we are developing a plugin(http://wiki.llvm.org/Polyhedral_optimization_framework) for LLVM, and need to find the LLVM libraries directory so we can locate the loadable module. The testing guide said that we can locate the libraries directory by the variable "$llvmlibsdir". So i put this option after opt in the RUN line of test case: -load=$llvmlibsdir/LLVMPolly.so. but i got: Error

On Mon, Dec 28, 2009 at 05:05, Albert Cohen <Albert.Cohen at inria.fr> wrote: > PCP is only partially implemented: conversion out of PCP to Graphite is not > implemented, Actually Gimple to PCP to Graphite is implemented in some extent, but there still are plenty of bugs and we should work on the out of Graphite to PCP to Gimple/LLVM if we want to get rid of all these bugs. Also the

How is the patch compressed? I don't know how to open the file with .7z suffix. Evan On Feb 27, 2010, at 10:12 PM, ether zhhb wrote: > hi all, > > The patch in the attachment add a new pass - region pass to the llvm system. A region pass is similar to a loop pass, all of them execute on a group of BasicBlocks at one time, but it operate on a single entry single exit region, not the