similar to: [LLVMdev] "Graphite" for llvm

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.

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

Be careful about oversimplifying signed integer comparisons -- integer arithmetic can easily overflow, so you cannot transform A > B to A - B > 0. The compare instructions in most processors do not simply subtract and test the most significant bit; they compute what the sign of the difference would be in extended precision. On Apr 17, 2010, at 1:00 PM, llvmdev-request at cs.uiuc.edu 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. 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 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 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 again :) On Tue, Apr 13, 2010 at 8:57 AM, ether zhhb <etherzhhb at gmail.com> wrote: > hi john, > > thanks very much, i will try it out. > > --best regards > ether > > > On Mon, Apr 12, 2010 at 10:03 PM, John Criswell <criswell at uiuc.edu> wrote: > >> ether zhhb wrote: >> >>> hi all, >>> >>> i have some thing

Hi, i am playing the ScalarEvolution these days. i found the the ScalarEvolution will simply return a SCEVUnknow for a ICmpInst, so i think maybe great to add a new kind of SCEV to the ScalarEvolution framework. for example, if i run ScalarEvolution on the bc file generate from the following C source file: int f(int a, int b, int c, int d) { return (2 * a + 5 * c + 2) > (4 * d - 3*b

On Tue, Jan 27, 2015 at 9:13 PM, Markus "Shorty" Uckelmann <shorty at koeln.de> wrote: > 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. > There's a .spec file that the author ran

ether zhhb wrote: > hi John, > > sorry for reply so late. > > On Tue, Apr 13, 2010 at 10:38 PM, John Criswell <criswell at uiuc.edu > <mailto:criswell at uiuc.edu>> wrote: > > Devang Patel wrote: > > On Mon, Apr 12, 2010 at 6:41 PM, ether zhhb > <etherzhhb at gmail.com <mailto:etherzhhb at gmail.com>> wrote: > >

Hi Ether, The detection for graphviz / dotty / ... has been added recently to llvm cmake. It should work properly if those tools are available in the PATH. The related svn commits are : 86153, 86547 and 86644. Those commits are not present in llvm release <= 2.6, but they are straight forward to apply. Best regards, -- Arnaud de Grandmaison -----Original Message----- From: llvmdev-bounces at

Hi Ether, I work under Windows and am able to view graphs generated by LLVM. I haven't tried generating and viewing dog graphs while debugging but I hope this helps. What I do is to invoke llc.exe and pass a switch to generate the graph at the stage(s) you want to see (DAG combine, legalize, scheduling, etc), for example: llc.exe mykernel.ll -view-legalize-dags -f. The graphs are saved

hi John, sorry for reply so late. On Tue, Apr 13, 2010 at 10:38 PM, John Criswell <criswell at uiuc.edu> wrote: > Devang Patel wrote: > >> On Mon, Apr 12, 2010 at 6:41 PM, ether zhhb <etherzhhb at gmail.com> wrote: >> >> >> >>> that's because FunctionPass implement the "addLowerLevelRequiredPass" >>> function, but others