similar to: Developing a module: Use it from the current directory?

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

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

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

My environment: Ubuntu LTS 12.04, carbon (https://github.com/graphite-project/carbon) 0.9.9 installed using "pip". I just learned why when I run "pip freeze" on a system I don''t see the "carbon" package even when it installed successfully - I should run it with "PYTHONPATH=/opt/graphite/lib/ pip freeze". (ref:

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:

Hi, I wish to develop a web crawler in R. I have been using the functionalities available under the RCurl package. I am able to extract the html content of the site but i don't know how to go about analyzing the html formatted document. I wish to know the frequency of a word in the document. I am only acquainted with analyzing data sets. So how should i go about analyzing data that is not

Is there a timeline for when dragonegg might be merged into gcc (4.6 perhaps)? I ask because FSF gcc has allowed code in as technology previews before. For instance, graphite really wasn't that usable in gcc 4.4 and produced wrong code in the Polyhedron 2005 benchmarks until gcc 4.5. So as long as it can bootstrap gcc 4.6 and works in general, dragonegg should qualify for inclusion as an

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 Jack, > Is there a timeline for when dragonegg might be > merged into gcc (4.6 perhaps)? I ask because FSF gcc > has allowed code in as technology previews before. > For instance, graphite really wasn't that usable in > gcc 4.4 and produced wrong code in the Polyhedron > 2005 benchmarks until gcc 4.5. So as long as it can bootstrap > gcc 4.6 and works in general,

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 Fri, Apr 09, 2010 at 04:14:17PM +0200, Duncan Sands wrote: > Hi Jack, > > > Is there a timeline for when dragonegg might be > > merged into gcc (4.6 perhaps)? I ask because FSF gcc > > has allowed code in as technology previews before. > > For instance, graphite really wasn't that usable in > > gcc 4.4 and produced wrong code in the Polyhedron >

I have been using the nls function to fit some simple non-linear regression models for properties of graphite bricks to historical datasets. I have then been using these fits to obtain mean predictions for the properties of the bricks a short time into the future. I have also been calculating approximate prediction intervals. The information I have suggests that the assumption of a normal

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

Hello. I've got many (5-20k) files with time series in a text format like this: 1359635460 2.006747 1359635520 1.886745 1359635580 3.066988 1359635640 3.633578 1359635700 2.140082 1359635760 2.033564 1359635820 1.980123 1359635880 2.060131 1359635940 2.113416 1359636000 2.440172 First field is a unix timestamp, second is a float number. Its

Hello, I've been playing around with the really simple example of not cache friendly loop like this: #define N 100 void foo(int** __restrict__ a, int** __restrict__ b) { for (int i = 0; i < N; ++i) for (int j = 0; j < N; ++j) a[j][i] += b[j][i]; } link to compiler explorer:

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