similar to: [LLVMdev] Memory dependence analysis

On 6/22/11 5:34 AM, Andreas Wilhelm wrote: > Hello, > > I'm looking for a way to identify dependencies of > function-pairs (memory-dependency, control-dependency...) in order to > parallelize them. > For aliasing problems I use the DataStructureAnalysis. I'm assuming that this is the DSA analysis in the poolalloc module. Be forewarned that: 1) DSA works with LLVM

On 22.06.2011, at 17:03, John Criswell wrote: > On 6/22/11 5:34 AM, Andreas Wilhelm wrote: >> >> Hello, >> >> I'm looking for a way to identify dependencies of function-pairs (memory-dependency, control-dependency...) in order to parallelize them. >> For aliasing problems I use the DataStructureAnalysis. > > I'm assuming that this is the DSA

Hi, I am not exactly sure what causes your error. But if you have a reduced test case we can try looking at it. Thanks, Arushi Hello, i wrote a little pass. It tries to identify every call- / invoke-instruction recursively and calls computeCalleeCallerMapping for each. The sample program just creates a vector of integer and adds an element to it. Do you know what's wrong? Best,

Hi, during the hunt for a bug causing strange behavior of our automatic parallelization framework, I found some, at least for me, unexpected behavior of the DataStructureAnalysis in Poolalloc. Consider the following simplified program: ==================== int ARR[4] = {1, 2, 3, 4}; int a(int pos) { return ARR[pos]; } int sum(int op_a, int op_b) { return a(op_a) + a(op_b); } int

Hi, though DSA isn't maintained in the current build, I need to use it for analyzing dependencies among functions. Therfore I load the EQTDDataStructures pass and retrieve the mapping from nodes int the callee to the ones in the parent DSGraph with computeNodeMapping. In most cases this works well, but for some function calls I get following error: DSGraph.cpp:1379: static void

Hi, I have been trying to run the memdep analysis using opt with the following command: opt -analyze -memdep <*.bc>. However, I keep getting the following error: Pass::print not implemented for pass: 'Memory Dependence Analysis' ! . I get similar errors for a lot of the analyses passes, which seem as if they should have a print out? Is there any other memory dependence analysis

Chris Lattner schrieb: > > On Aug 20, 2009, at 11:44 AM, Marc Brünink wrote: > >> Hi, >> >> I do have a FunctionPass that does change the code. This FunctionPass >> requires another FunctionPass which performs all the necessary analyses. >> This AnalysisPass again requires MemoryDependenceAnalysis. >> >> The problem is, that I would like

On Aug 21, 2009, at 3:04 AM, Marc Brünink wrote: >> This isn't really possible. The issue is that MemDep doesn't just >> "analyze your function". It is designed to be as lazy as possible, >> which means that it only does analysis when a query is performed. >> This >> means that if you have MemDep->Pass1->Pass2 and Pass2 uses MemDep

Chris Lattner schrieb: > On Aug 21, 2009, at 3:04 AM, Marc Brünink wrote: >>> This isn't really possible. The issue is that MemDep doesn't just >>> "analyze your function". It is designed to be as lazy as possible, >>> which means that it only does analysis when a query is performed. This >>> means that if you have

On 03/28/2011 12:15 PM, Nipun Arora wrote: > Hi, > > I have been trying to run the memdep analysis using opt with the > following command: opt -analyze -memdep <*.bc>. > However, I keep getting the following error: Pass::print not implemented > for pass: 'Memory Dependence Analysis' ! . > I get similar errors for a lot of the analyses passes, which seem as if

On Aug 20, 2009, at 11:44 AM, Marc Brünink wrote: > Hi, > > I do have a FunctionPass that does change the code. This FunctionPass > requires another FunctionPass which performs all the necessary > analyses. > This AnalysisPass again requires MemoryDependenceAnalysis. > > The problem is, that I would like MemoryDependenceAnalysis to run on > the > unaltered

Define soon? My guess is 1 year or less. (I've already seen patches to start converting most remaining memdep uses, like memcpy opt, licm, etc) On Fri, Dec 23, 2016 at 8:27 AM, Piotr Padlewski via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > 2016-12-23 17:22 GMT+01:00 Davide Italiano <davide at freebsd.org>: > >> On Fri, Dec 23, 2016 at 8:12 AM, Piotr

> Wojtek, > > Please see David's message below. Have you or can you check in your > code, perhaps as a project for now? That will allow us to start > looking at it and perhaps collaborating on it. Sure. For now, I am posting it as an attachment, because it does not build against the current SVN version. It is really basic (for example, it cannot produce distance vectors,

2016-12-23 17:22 GMT+01:00 Davide Italiano <davide at freebsd.org>: > On Fri, Dec 23, 2016 at 8:12 AM, Piotr Padlewski via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi everyone, > > > > I started digging into MemDep to enhance devirtualization and I found out > > that it doesn't handle invariant.group if it will find GEP 0, 0. > > If I

Hi, MemDep caches results for local queries and provides means to invalidate them by keeping reverse maps. Unfortunately, it also caches results that represent non-local dependencies, for which there are no reverse map entries, and thus those entries can not be invalidated. This is a problem when an optimization turns a non-local dependency into a local one.

Thanks Daniel, I'll do a debug build of LLVM (I guess that'll teach me) and step through it as soon as I'll find a power outlet. I'm calling getDependency on the load instruction, and it returns the store instruction. Suspiciously enough, calling invalidateCachedPointerInfo on load->getPointerOperand() does not cause my AA pass to be called again when I use getDependency (or

Hello, We are now facing a bug caused by the GVN pass, only part of the code was optimized. I have found that the problem is cause by an Limit in lib/Analysis/MemoryDependenceAnalysis.cpp 00055 static cl::opt<unsigned> BlockScanLimit( 00056 "memdep-block-scan-limit", cl::Hidden, cl::init(100), 00057 cl::desc("The number of instructions to scan in a block in

On Fri, Aug 21, 2009 at 10:48 AM, Marc Brünink<marc at bruenink.de> wrote: >>> actually my problem is easier. So I still have hope that it is possible: >>> >>> MemDep->Pass1->Pass2 >>> >>> Pass1 uses MemDep. Pass2 only uses Pass1. Eventually, Pass2 changes the >>> code. Unfortunately, non-local dependencies of MemDep might point to

add -basicaa to your command line :) On Mon, May 11, 2015 at 7:15 AM, Willy WOLFF <willy.mh.wolff at gmail.com> wrote: > I play a bit more with MemoryDependenceAnalysis by wrapping my pass, and > call explicitely BasicAliasAnalysis. Its still using No Alias Analysis. > > How can I let MemoryDependenceAnalysis use BasicAliasAnalysis? > > Please, find attached my pass. >

On 3/4/13 8:05 AM, Kevin Streit wrote: > Hi, > > during the hunt for a bug causing strange behavior of our automatic > parallelization framework, > I found some, at least for me, unexpected behavior of the > DataStructureAnalysis in Poolalloc. > > Consider the following simplified program: > > ==================== > int ARR[4] = {1, 2, 3, 4}; > > int a(int