similar to: [LLVMdev] "Graphite" for llvm

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

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

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!

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

On 02/07/2012 05:12 PM, David A. Greene wrote: > > 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?

On Tue, Jan 27, 2015 at 10:23 PM, Markus "Shorty" Uckelmann <shorty at koeln.de> wrote: > Am 28.01.2015 um 07:07 schrieb Philip Keogh: >> You can also likely use this Fedora tree: >> http://pkgs.fedoraproject.org/cgit/graphite-web.git/tree/ > > That's the one I already found. But I wasn't sure in which state this > was. So you mean this is

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 Sjoerd, On 09/20, Sjoerd Meijer wrote: > I have not been following the polyhedral developments in both GCC and > LLVM very closely the last few years, but I was just wondering if > there are any lessons learned we should look at (or actually already > aware of) in GCC's implementation and integration of Graphite. For > example, do we know if it is (still) enabled/used/etc.?

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?)? thanks --ether