similar to: [LLVMdev] "Graphite" for llvm

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.

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

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

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

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

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

On 04/26/2013 05:08 AM, tanmx_star wrote: > Hi all, Hi, thanks for the update and sorry for the delay in reviewing. I just had a look at your proposal. > I have updated my GSoS proposal: "FastPolly: Reducing LLVM-Polly Compiling overhead" (https://gist.github.com/tanstar/5441808). I think the pass ordering problem you discussed early can be also investigated in this project!

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

Preston Briggs <preston.briggs at gmail.com> writes: > 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) >

Hi all, I have updated my GSoS proposal: "FastPolly: Reducing LLVM-Polly Compiling overhead" (https://gist.github.com/tanstar/5441808). I think the pass ordering problem you discussed early can be also investigated in this project! Is there any comment or advice about my proposal? I appreciate all your help and advice. Thanks, Star Tan Proposal:

Am 28.01.2015 um 07:07 schrieb Philip Keogh: Hi Philip, > There's a .spec file that the author ran through mock on EL7: > https://github.com/mckern/carbon/blob/rpm_spec/rpm_spec/carbon.spec By author you mean the author of the RPM? > (If you need to know how to generate an RPM from a .spec see > https://fedoraproject.org/wiki/How_to_create_an_RPM_package ) Ta. > You can

Hi folks, Does anyone know if and when RPMs for "graphite-web" will be available in CentOS 7? I know that this relates to EPEL, but maybe someone here can help me out or point me to soemplace/-one who knows. Thx and regards, Shorty -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc:

On Mon, Sep 12, 2011 at 10:44, Tobias Grosser <tobias at grosser.es> wrote: >> 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 this does not work. I mean you could rewrite that code to work on a per loop basis, like

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 09/12/2011 04:56 PM, Sebastian Pop wrote: > On Mon, Sep 12, 2011 at 10:44, Tobias Grosser<tobias at grosser.es> wrote: >>> 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 this does not work. >

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 05/03/2013 11:39 AM, Star Tan wrote: > Dear Tobias, > > > Thank you very much for your very helpful advice. > > > Yes, -debug-pass and -time-passes are two very useful and powerful > options when evaluating the compile-time of each compiler pass. They > are exactly what I need! With these options, I can step into details > of the compile-time overhead of each pass.

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

In general, the loading/import/namespacing mechanism is really something that I cannot wrap my head around, even after reading the relevant sections in the documentation. Specifically, I''m trying to put together a module. I believe I have the correct module structure: $ find . ./test.pp ./graphite ./graphite/manifests ./graphite/manifests/init.pp ./graphite/files