search for: dependenceanalysis

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 memory access pairs from the basic blocks within the CFG of the loop body which wou...

Hi, I am trying to use the DependenceAnalysis pass to get the Distance vector for the innermost loop. I am in LLVM learing process. I have used the following code inside my original code to get the distance vector. It is not giving any syntax error but it is has some logical but and giving segmentation fault. void getAnalysisUsage(AnalysisUsa...

Hi, I want to create a copy of DependenceAnalysis downstream. At first I tried the HelloWorld tutorial. But then I figured, maybe I should move on to create my pass by mimicking some other pass in LLVM. So, I tried copying DependenceAnalysis itself [1] Although after a lot of time of trying it compiled, I'm pretty sure I have done it comple...

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

...ser.es> > To: "preston briggs" <preston.briggs at gmail.com> > Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, November 2, 2012 12:56:53 PM > Subject: Re: [LLVMdev] DependenceAnalysis and PR14241 > > On 11/02/2012 10:21 AM, Preston Briggs wrote: > > > > My initial guess is that a conservative fix is quick and small > > (make > > sure the underlying pointers are loop invariant, otherwise give > > up). A > > better approach would be to so...

...105b0202b raise + 27 > 6 libLLVM-3.3svn.dylib 0x0000000105b020e2 abort + 18 > 7 libLLVM-3.3svn.dylib 0x0000000105b020c1 __assert_rtn + 129 > 8 libLLVM-3.3svn.dylib 0x0000000104d570e1 llvm::ScalarEvolution::getSCEV(llvm::Value*) + 145 > 9 libLLVM-3.3svn.dylib 0x0000000104c3c7ac llvm::DependenceAnalysis::depends(llvm::Instruction*, llvm::Instruction*, bool) + 2076 > 10 Hello.dylib 0x000000010871221a llvm::Hello::countMemoryDependences() + 858 > 11 Hello.dylib 0x000000010872b073 llvm::Hello::initialize(llvm::Loop*) + 691 > 12 Hello.dylib 0x00000...

Hi all, I have been looking at the `DependenceAnalysis` pass in `llvm/include/llvm/Analysis/DependenceAnalysis.h`. In order for this analysis to produce accurate dependence vectors for multi-dimensional arrays in nested loops, it needs to "delinearize" array element accesses to recover the subscripts in each dimension of the array. I believe...

Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> writes: > LLVM has multiple dependence analyses, each with its up- and downsides: > > * llvm::DependenceAnalysis > * llvm::LoopAccessAnalysis Can someone explain the differences between these? As far as I can tell they essentially do the same thing (though perhaps one is more precise?). LAA seems to be used by vectorization (what else?) while DA seems to be used by loop transformations (what else?). I...

On 11/02/2012 10:21 AM, Preston Briggs wrote: > > My initial guess is that a conservative fix is quick and small (make > sure the underlying pointers are loop invariant, otherwise give up). A > better approach would be to somehow turn code like the example into > array references that can be analyzed. I'll need to think about this and > do some reading. Hi Preston, I looked

...gt; To: "preston briggs" <preston.briggs at gmail.com> >> Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Friday, November 2, 2012 12:56:53 PM >> Subject: Re: [LLVMdev] DependenceAnalysis and PR14241 >> >> On 11/02/2012 10:21 AM, Preston Briggs wrote: >>> >>> My initial guess is that a conservative fix is quick and small >>> (make >>> sure the underlying pointers are loop invariant, otherwise give >>> up). A >>> bette...

...ggs" <preston.briggs at gmail.com> >>> Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "LLVM Developers Mailing >>> List" <llvmdev at cs.uiuc.edu> >>> Sent: Friday, November 2, 2012 12:56:53 PM >>> Subject: Re: [LLVMdev] DependenceAnalysis and PR14241 >>> >>> On 11/02/2012 10:21 AM, Preston Briggs wrote: >>> >>>> >>>> My initial guess is that a conservative fix is quick and small >>>> (make >>>> sure the underlying pointers are loop invariant, otherwise give &...

Hey Preston, I wanted to let you know that we found a really serious problem with DependenceAnalysis in PR14241. In summary, DA seems to have a baked-in assumption that the base pointer of the GEPs it inspects are loop invariant. It appears to only do analysis on the subscripts. This is especially important for LLVM because C++ code (compiled through Clang) very frequently expresses loops as poin...

...avid.Green at arm.com> To: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Bardia Mahjour <bmahjour at ca.ibm.com> Cc: nd <nd at arm.com> Date: 2019/05/14 02:50 PM Subject: [EXTERNAL] Re: [llvm-dev] Delinearization validity checks in DependenceAnalysis Hello Interestingly, the example you provide works for me so long as either it's a 32bit target, or the array bounds (n and m) are changed to unsigned. For a bit of history, DA used to have a different delinearisation method based on geps, but it was known to be invalid in same cases and w...

Valmico <valmico88 at gmail.com> wrote: > I'm currently trying to develop new LLVM Pass that will generate > simple data dependencies graph. For now I'm trying to get familiar > with DependenceAnalysis. > My general idea is to traverse each function (runOnFunction) > top to bottom Instruction by Instruction, using DA.depends( I, I2, ...) > on every Instructions combination in function to check if they are > dependent on any others. > > Problem is that almost all (if not all) Ins...

Hi Chandler, Thanks for writing. Could you give me some C (or C++) for an illustrative example. I think I understand your concern, but I'd like to be sure. Thanks, Preston -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121102/88c02212/attachment.html>

On 02.11.2012, at 15:53, Preston Briggs <preston.briggs at gmail.com> wrote: > Hi Chandler, > > Thanks for writing. > Could you give me some C (or C++) for an illustrative example. > I think I understand your concern, but I'd like to be sure. Hi Preston, The bug report at http://llvm.org/bugs/show_bug.cgi?id=14241 has more details, including a C++ test case. - Ben

I see, thanks Ben. So yes, I certainly misunderstood (more likely "misunderstand") how things work. My initial guess is that a conservative fix is quick and small (make sure the underlying pointers are loop invariant, otherwise give up). A better approach would be to somehow turn code like the example into array references that can be analyzed. I'll need to think about this and do

Below is a stripped down version of the pass. The compile line is: clang -O0 -S -emit-llvm -o test.S test.c && opt -S -mem2reg -load <path to extract lib> -extract < test.S > test_opt.S #include "llvm/Analysis/DependenceAnalysis.h" #include "llvm/Analysis/LoopInfo.h" #include "llvm/Analysis/LoopPass.h" #include "llvm/Analysis/ScalarEvolution.h" #include "llvm/Function.h" #include "llvm/Module.h" #include "llvm/Pass.h" #include "llvm/Support/raw_ostream.h...

...uot;llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Bardia >             Mahjour <bmahjour at ca.ibm.com> > Cc:   nd <nd at arm.com> > Date: 2019/05/14 02:50 PM > Subject:      [EXTERNAL] Re: [llvm-dev] Delinearization validity checks in >             DependenceAnalysis > > > > Hello > > Interestingly, the example you provide works for me so long as either it's > a 32bit target, or the array bounds (n and m) are changed to unsigned. > > For a bit of history, DA used to have a different delinearisation method > based on geps,...

...LLVM patch as well? > > > With this pass, we get 103 loop fusions in SPECCPU INT 2006 > 462.libquantum with rate performance improving close to 2.5X in x86 > (results from AMD A10-6700). > > > I took some liberties in patching up some of the code in > ScalarEvolution/DependenceAnalysis/GlobalsModRef/Clang options/ and > also adjusted the IPO/LTO pass managers. I would need to do a better > job there but I would like to put this out as WIP for high level > reviews. At this time standard loop fusion test cases may not work > (cases where control dep are same or loops ar...