search for: autoparallelization

Hi Timothy, > We would like to inform the community that we're releasing a version of our research compiler, "AESOP", developed at UMD using LLVM. AESOP is a distance-vector-based autoparallelizing compiler for shared-memory machines. The source code and some further information is available at > > http://aesop.ece.umd.edu > > The main components of the released

On 03/03/2013 02:09 PM, Timothy Mattausch Creech wrote: > Hi, > We would like to inform the community that we're releasing a version of our research compiler, "AESOP", developed at UMD using LLVM. AESOP is a distance-vector-based autoparallelizing compiler for shared-memory machines. The source code and some further information is available at > >

Hi, We would like to inform the community that we're releasing a version of our research compiler, "AESOP", developed at UMD using LLVM. AESOP is a distance-vector-based autoparallelizing compiler for shared-memory machines. The source code and some further information is available at http://aesop.ece.umd.edu The main components of the released implementation are loop memory

----- Original Message ----- > From: "Timothy Mattausch Creech" <tcreech at umd.edu> > To: "Sebastian Dreßler" <dressler at zib.de> > Cc: "Aparna Kotha" <akotha at umd.edu>, llvmdev at cs.uiuc.edu > Sent: Sunday, March 3, 2013 11:32:49 AM > Subject: Re: [LLVMdev] AESOP autoparallelizing compiler > > Hi Sebastian, > Sure!

Hi, On 03/03/2013 07:09 AM, Timothy Mattausch Creech wrote: > [...] > The main components of the released implementation are loop memory > dependence analysis and parallel code generation using calls to POSIX > threads. The loop memory dependence analysis sounds very interesting to me. Could you provide some more information regarding its capabilities? Cheers, Sebastian -- Mit

On Mon, Mar 04, 2013 at 03:01:15PM +0800, 陳韋任 (Wei-Ren Chen) wrote: > Hi Timothy, > > > We would like to inform the community that we're releasing a version of our research compiler, "AESOP", developed at UMD using LLVM. AESOP is a distance-vector-based autoparallelizing compiler for shared-memory machines. The source code and some further information is available at

Hi Timothy, Today I happened to download the code and do some experiments. I actually wanted to see how you handle inter-procedure alias analysis. So, I set inline threshold to zero and tried out following example =============================================== #define N 1024 void func(double *A, double *B) { int i; for (i=1; i<N-2; i++) { B[i] = A[i] + i*3; } } void func1(double

Hi Rahul, Thanks for your interest! Our work does not attempt to make any significant contributions to alias analysis, and acts as a client to existing LLVM AA. Furthermore, the options passed to the AESOP frontend scripts are obeyed at compile time, but at link time certain transformations occur unconditionally. Here, AESOP has actually thwarted your experiment by performing inlining just

Hi Sebastian, Sure! The bulk of LMDA was written by Aparna Kotha (CCd). It computes dependences between all instructions, computes the resulting direction vectors in the function, then associates them all with loops. At a high level, the dependence analysis consults with AliasAnalysis, and ScalarEvolution before resorting to attempting to understand the effective affine expressions and

...2->S1 , RAW - S3->S2 C1 (false) : WAW - S3->S1 So then it seems to me that building the dependence graph is essential. Are there no other Analysis/Transforms which require this type of information? I looked at AESOP (http://aesop.ece.umd.edu/doc/aesop-white-paper.pdf) which implements an autoparallelization framework and it seems they would need to do similar checks, the page hosting the code is currently offline. Thanks, Snehasish On Fri, Dec 27, 2013 at 12:24 PM, Preston Briggs <preston.briggs at gmail.com>wrote: > Hi, > > There's no implementation yet of the dependence graph...

Hello: We are working with LLVM-3.1 and we have a problem.This is the code we have executed: virtual void getAnalysisUsage( llvm::AnalysisUsage & info ) const { info.addRequired<CallGraph>(); ... } ... virtual bool runOnModule( Module & M ) { ... CallGraph &CG = this->getAnalysis<CallGraph>(); CallGraphNode *cgn; unsigned nref;

Hello: We are developer-engineers of Appentra Solutions. We are working with LLVM-3.1 and we have a problem. We think we have found a bug on CallGraphNode. This is the code we have executed: virtual void getAnalysisUsage( llvm::AnalysisUsage & info ) const { info.addRequired<CallGraph>(); ... } ... virtual bool runOnModule( Module & M ) { ... CallGraph &CG =

Hello R Programmers, We have a large existing Perl codebase which is currently being upgraded to use the new optimizing RPerl compiler (not related to the R language). http://rperl.org/ Also in use by the same Perl codebase is some custom R code which loads the "bayesm" library in order to execute Markov Chain Monte Carlo (MCMC) calculations.

Hello, I had earlier mailed the list[1] about adding OpenMP support to Clang and LLVM Polly. The LLVM Polly wiki page earlier mentioned a design[2] where Clang and LLVM Polly would emit annotations to the code and there would be a seperate pass that would transform the code using these annotations. The issue I see with this approach is that this pass will have to be run immediately after the

Hi I want to analyse the memory dependencies which exist in a loop at an intra iteration as well as inter iteration (loop carried dependencies). I looked at the DependenceAnalysis implementation which returns a lot of the information I require (based on a prior AliasAnalysis pass), however I need to pass the Src and Dst instructions in program order. I was wondering how I can collect all the

On 09/22/2017 12:03 AM, Mehdi AMINI wrote: > Hi Hal, > > > 2017-09-21 20:59 GMT-07:00 Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: > > > On 09/12/2017 10:26 PM, Gerolf Hoflehner wrote: >> >> >>> On Sep 11, 2017, at 10:47 PM, Hal Finkel via llvm-dev >>> <llvm-dev at

Hi Hal, 2017-09-21 20:59 GMT-07:00 Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> : > > On 09/12/2017 10:26 PM, Gerolf Hoflehner wrote: > > > > On Sep 11, 2017, at 10:47 PM, Hal Finkel via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > On 09/11/2017 12:26 PM, Adam Nemet wrote: > > Hi Hal, Tobias, Michael and others, > *...* >

2017-09-21 22:22 GMT-07:00 Hal Finkel <hfinkel at anl.gov>: > > On 09/22/2017 12:03 AM, Mehdi AMINI wrote: > > Hi Hal, > > > 2017-09-21 20:59 GMT-07:00 Hal Finkel via llvm-dev < > llvm-dev at lists.llvm.org>: > >> >> On 09/12/2017 10:26 PM, Gerolf Hoflehner wrote: >> >> >> >> On Sep 11, 2017, at 10:47 PM, Hal Finkel via

On 09/22/2017 12:25 AM, Mehdi AMINI wrote: > > > 2017-09-21 22:22 GMT-07:00 Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>>: > > > On 09/22/2017 12:03 AM, Mehdi AMINI wrote: >> Hi Hal, >> >> >> 2017-09-21 20:59 GMT-07:00 Hal Finkel via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at

> On Sep 11, 2017, at 10:47 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 09/11/2017 12:26 PM, Adam Nemet wrote: >> Hi Hal, Tobias, Michael and others, >> >>> On Sep 1, 2017, at 11:47 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>>