search for: releasememory

Hi all, While working on a loadable Alias Analysis module pass, I'm running into the following issue: I'm finding my pass queried for results after it has had 'releaseMemory' called on it and its dependencies, but before runOnModule is called again (on my pass or its deps). As you might expect, this makes my pass rather unhappy (and I think correctly so). This happens with LICM and it's use of AliasSetTracker, here's an excerpt from opt -debug-pass=Execut...

On Jun 29, 2010, at 9:59 AM, Will Dietz wrote: > Hi all, > > While working on a loadable Alias Analysis module pass, I'm running > into the following issue: > > I'm finding my pass queried for results after it has had > 'releaseMemory' called on it and its dependencies, but before > runOnModule is called again (on my pass or its deps). As you might > expect, this makes my pass rather unhappy (and I think correctly so). > > This happens with LICM and it's use of AliasSetTracker, here's an > excerpt fr...

...ve to manage the memory, satisfy its needs and ensure validity of the info yourself. You could do something like, LoopInfo LI; DominatorTree DT; .... DT.recalculate(F) LI.Calculate(DT.getBase()); ... ... use LI ... /* Make sure F is not modified since DT and LI were calculate. */ ... DT.releaseMemory(); LI.releaseMemory(); - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111116/3da1e43c/attachment.html>

In order to detect whether CallSite is present in innermost loop, do I need to insert logic from LoopInfo pass for collecting loops, within a CallGraphSCC pass?   Is there any other approach for this?   Regards, Pankaj -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111116/cd9d51b7/attachment.html>

...lass. That worked in LLVM 2.6, but now in LLVM 2.7 I'm getting strange behavior. In particular, I'm seeing the wrong functions called when virtual methods of my passes are called. For example, when a SAFECode pass would call the getDSGraph() method of the PoolAllocateSimple pass, the releaseMemory() method would be called instead. Has anyone else seen this really bizarre behavior or know what might be causing it? Eliminating multiple inheritance seems to fix the problem, but it seems to introduce other problems when chaining analysis passes of the same group together. I see this behav...

...ncredibly poor job answering your question :) You have it exactly right. Currently if you have a function pass, it is created once per function, and any other functionpass that requires it will see its results. The pass manager tells your pass that all clients are done with it by calling the releaseMemory method: http://llvm.cs.uiuc.edu/docs/WritingAnLLVMPass.html#releaseMemory That is the place you should "flush" the contents of the analysis. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/

Hi, There are two relevant hooks for you immutable pass: 1) releaseMemory() 2) doFinalization() Are you looking at the first one? I think you should act on the second instead and it should solve your issue. — Mehdi > On Dec 8, 2016, at 10:58 AM, Maxime Chevalier-Boisvert via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > We have our own subtarget,...

On Sat, Apr 02, 2005 at 11:35:30AM -0600, Chris Lattner wrote: > On Sat, 2 Apr 2005, Sameer D. Sahasrabuddhe wrote: > > I want to create a simple map from a Value to the instruction that > > defines it. Such a map is present inside SchedGraph, but I need it in > > a much simpler context. > > Is this in the context of the code generator? No ... I am just trying to feel

...a + 1; }; ...... For the loop analyzation I use the ScalarEvolution class with the following initialization: ...... void analysis(Function* func) DominatorTree DT = DominatorTree(); DT.recalculate(*func); DT.updateDFSNumbers(); LoopInfoBase<BasicBlock, Loop> LIB; LIB.releaseMemory(); LIB.analyze(DT); for(auto&bb :*func){ Loop * L = LIB.getLoopFor(&bb); if(L != nullptr){ AssumptionCache AC = AssumptionCache(*bb.getParent()); Triple MT(llvm::sys::getDefaultTargetTriple()); TargetLibraryInfoImpl TLII(MT);...

...n() calls. So now I clear the >> Intervals vector in destroy() and call destroy() to start on a clean >> state before doing the processing (as was done earlier) in >> runOnFunction. I am attaching the patch with this mail. > > The right fix for this is to rename destroy() to releaseMemory(). > Does that work? Yeah, that works. Thanks ! - Prakash > > -Chris > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >

...ss BaseClass : public ModulePass { // Name for printing const char* printname; protected: BaseClass(char id, const char* name) : ModulePass(id),printname(name){ } }; class Pass1 : public BaseClass { public: static char ID; Pass1() : BaseClass(ID, "pass1") { } ~Pass1() { releaseMemory(); } virtual bool runOnModule(Module &M); virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesAll(); } }; class Pass2 : public BaseClass { public: static char ID; Pass2() : BaseClass(ID, "pass2") { } ~Pass2() { releaseMemory(); } virtual bool...

...{ ... A &X = getAnalysis<A>(F1); ... A &Y = getAnalysis<A>(F2); ... } Will X and Y reference the same object here? It's not a problem for me, as I don't need results of analysis of both functions at the same time. However, I wonder, if I should explicitly call releaseMemory() method after the first analysis. Thanks in advance for the answer. -Wojtek

I'm getting a lot of these from TOT make: /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h: In instantiation of 'llvm::LoopInfoBase<llvm::BasicBlock>': /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:886: instantiated from here /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:573: warning: 'class

...eird, I did not get this error. If following helps, please apply. Thanks, - Devang Index: LoopInfo.h =================================================================== --- LoopInfo.h (revision 48476) +++ LoopInfo.h (working copy) @@ -580,9 +580,6 @@ LoopInfoBase() { } ~LoopInfoBase() { releaseMemory(); } - /// isAnalysis - Return true if this pass is implementing an analysis pass. - virtual bool isAnalysis() const { return true; } - void releaseMemory() { for (typename std::vector<LoopBase<BlockT>* >::iterator I = TopLevelLoops.begin(), E = TopLevelLoops....

...ifferent runOnFunction() calls. So now I clear the > Intervals vector in destroy() and call destroy() to start on a clean > state before doing the processing (as was done earlier) in > runOnFunction. I am attaching the patch with this mail. The right fix for this is to rename destroy() to releaseMemory(). Does that work? -Chris

...gt; 2.6, > but now in LLVM 2.7 I'm getting strange behavior. In particular, I'm > seeing the wrong functions called when virtual methods of my passes > are > called. For example, when a SAFECode pass would call the getDSGraph() > method of the PoolAllocateSimple pass, the releaseMemory() method > would > be called instead. > > Has anyone else seen this really bizarre behavior or know what might > be > causing it? Eliminating multiple inheritance seems to fix the > problem, > but it seems to introduce other problems when chaining analysis passes >...

...it appears it's known and understood but not fixed because no one need it yet...which is understandable. I imagine that puts this in "patches welcome" territory? >> While I'm at it, a related question.  The wording from >> http://llvm.org/docs/WritingAnLLVMPass.html#releaseMemory suggests >> that you can count in PassManager calling 'releaseMemory' before >> calling the next run* method.  Is this a strict requirement?  Working >> around this is easy, but I suppose I'm asking if that's not the >> behavior I see is that something I shou...

...dStoreElim = createDeadStoreEliminationPass(); DeadStoreElim->runOnFunction(Current1); cerr << "Loop Unroll" << std::endl; LPPM = new LPPassManager(1); UnrollLoops = createLoopUnrollPass(); LPPM->add(UnrollLoops); LPPM->runOnFunction(Current2); LPPM->releaseMemory(); delete LPPM; LPPM = NULL; return true; } This tool compiles successfully, but I got errors when I apply it onto a program. DeadStoreElim = createDeadStoreEliminationPass(); DeadStoreElim->runOnFunction(Current1); This part of the tool outputs following error message: opt: /home...

...Fix up kill information for live intervals. Rescheduling may often have // changed which instruction is a value's last use, and we must update // kill flags and the kill information in the VarInfo objects. fixKillInformation(); // Now, release the stuff we computed, and recompute it! releaseMemory(); // Then, recompute the slot indexes. There is a function renumberIndexes, // but it doesn't respect our new ordering of instructions, so do this by // completely clearing the results of the slot index analysis and simply // calling it again. indexes_->releaseMemory(); indexes...

Hi Chris, Thanks for the reply. I am actually interested in using the Intervals Analysis mainly to be able to do Region based analysis. In fact, I found that the way Intervals are defined mirror exactly the definition of a Region in the second edition of the Dragon Book (Section 9.7 on Region-Based Analysis), so it will be great if the Intervals related code still lives on in LLVM :). I found