similar to: [LLVMdev] Request for compilers

Hi Ganesh, Please have a look at: These core parts of LLVM: http://llvm.org/docs/doxygen/html/classllvm_1_1Loop.html#a72bbf45d2e00971f56bf8cfe4e1df01c http://llvm.org/docs/Vectorizers.html These research projects based on LLVM: http://polly.llvm.org http://aesop.ece.umd.edu I'm not sure what you mean by "identify intrinsic functions". If you really mean LLVM intrinsics,

Hi I am trying to write up a transformation for the following code where instead of incrementing the loop variable by 1, I increment it by 2 ie. for (i=0; i < THRES; *i++*) { //do something } gets transformed to for (i=0; i < THRES; *i+=2*) { //do something } I am thinking of transforming the llvm bit-code in the following way. Iterate over the function for the original code till I

Malveeka, You can use the LoopInfo analysis to find the induction variable. http://llvm.org/docs/doxygen/html/classllvm_1_1Loop.html#a72bbf45d2e00971f56bf8cfe4e1df01c Cheers, Nadav From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Malveeka Tewari Sent: Thursday, May 05, 2011 14:51 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Loop transformations

On May 5, 2011, at 5:11 AM, Rotem, Nadav wrote: > Malveeka, > > You can use the LoopInfo analysis to find the induction variable. > > http://llvm.org/docs/doxygen/html/classllvm_1_1Loop.html#a72bbf45d2e00971f56bf8cfe4e1df01c > > Cheers, > Nadav getCanonicalInductionVariable is a good example of finding IVs without iterating over instructions. But you may need to

Ganesh, I modified DataStructure.cpp so that global nodes are no longer removed from any graphs. Only that file has changed. Chris, if you get a chance to do this, it would be nice if you could take a quick look at the change I made and make sure that's all that's needed. Thanks, --Vikram http://www.cs.uiuc.edu/~vadve > From: Chris Lattner <sabre at nondot.org> >

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

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

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

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

Hi Preston, Thank you for the prompt response. You can use DependenceAnalysis to get the info you want by expensively > testing all pairs of memory references. Isn't all pairs testing incorrect in the sense that a pair may only exist for a certain path? Consider the following example. A[i] = 42; // S1 if( condition ) // C1 { A[i] = 20; // S2 } B[i] = A[i];

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

Hi Stefanus, Thanks for verifying this. Could you patch this or should I open a new bug report and find a generic solution first? Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stefanus Du Toit Sent: woensdag 1 april 2009 18:59 To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Shuffle combine On 1-Apr-09, at 12:42

Hi Stefanus, Thanks for the info. I still think it's a bug though. Take for example a case where the vectors each have four elements. The values in Mask[] can range from 0 to 7, while HLSMask only has 4 elements. So LHSMask[Mask[i]] can go out of bounds, no? Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stefanus Du

Hi, I have a samba server configured with SECURITY=USER and am having trouble getting the UNIX PASSWORD SYNC to work. When I use smbpasswd to change a samba user password, everything goes well and the samba password is changed but the unix password is not changed. Per the manuals, samba trys to change the unix password first and if it fails, it will NOT change the samba password. However, the

Hi Nicolas, On 2-Apr-09, at 6:04 PM, Nicolas Capens wrote: > Thanks for verifying this. Could you patch this or should I open a > new bug report and find a generic solution first? I don't have write access so the best I could do would be to submit a patch, and I'm crazy busy at the moment. I actually think the check I described below is fine and would fix this bug (but

Hello, I am looking for a loop unfolding procedure implemented in LLVM that helps to transform a while-loop to n-layer If-statements. The transformation should be on IR, although the example below is illustrated on the source level. original loop: * WHILE (condition) DO action ENDWHILE* Expected unfolded loop (2-layer): * IF (condition) THEN* * action* * IF

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

On 1-Apr-09, at 12:42 PM, Nicolas Capens wrote: > Hi Stefanus, > > Thanks for the info. I still think it’s a bug though. Take for > example a case where the vectors each have four elements. The values > in Mask[] can range from 0 to 7, while HLSMask only has 4 elements. > So LHSMask[Mask[i]] can go out of bounds, no? Good point! One easy way to fix this would be to use: