Dear John, First thing, the 3 loops in Densemap are all " Loop at depth 1 containing: %1<header><exiting>,%3,%5<latch> " in the 3 functions. The dense map is in a ImmutablePass. I got it in FunctionPass and tried insert the information in this FunctionPass. So to turn the FunctionPass to ModulePass may be a better idea? Another interesting thing: if just before the insertion, I used "L -> print(errs());" to print the Loop, there were 6 items in ls. BUT when I tried to read it in a ModulePass, I can't get the correct result. " for (Module::iterator FI = M.begin(), E = M.end(); FI != E; ) { F = FI++; if (!F->hasName() && !F->isDeclaration()){} else{ LoopInfo *LI = &getAnalysis<LoopInfo>(*F); WCETInfo *WI = &getAnalysis<WCETInfo>(); //WI is the ImmutablePass which contains the dense map for(LoopInfo::iterator i=LI->begin(); i!=LI->end(); ++i) { Loop *L = *i; int lb=0; lb=WI->outls(L); // the method: return ls.find(L)->second; } } } " Thank you Sincerely, Hanbing ----- Mail original -----> De: "John Criswell" <jtcriswel at gmail.com> > À: "Hanbing Li" <hanbing.li at inria.fr>, llvmdev at cs.uiuc.edu > Envoyé: Jeudi 28 Août 2014 18:59:52 > Objet: Re: [LLVMdev] The problem of densemap and loop> Dear Hanbing,> You haven't provided enough information to help diagnose the problem. It > would help if you specified which 3 loops actually end up in the DenseMap.> One thing to check for is if your code is in a FunctionPass. A FunctionPass > computes its results anew each time it is run on a function, and so it's > possible that this is the cause of the problem. Similarly, the Loop objects > for each function might be deleted and re-allocated for new Loop objects > every time you run the LoopAnalysis on a new function. That would make it > look like you only have three elements when, in fact, you've added six > elements but three were deallocated.> Alternatively, you might have some something silly like making ls a local > variable, so it gets destroyed each time you enter the function/method in > which it appears.> However, these are just guesses. I'm not certain it can be diagnosed even if > you do provide more information.> Regards,> John Criswell> On 8/28/14, 12:49 PM, Hanbing Li wrote:> > Hello, everyone, >> > I created a dense map like this: DenseMap<Loop *, int> ls; > > > And I have a module which contains 3 functions: > > > function F and it has a loop which is " Loop at depth 1 containing: > > %1<header><exiting>,%3,%5<latch> " > > > function G and it has two loops which are " >> > Loop at depth 1 containing: %8<header><exiting>,%10,%14<latch> >> > Loop at depth 1 containing: %1<header><exiting>,%3,%5<latch> " > > > function main and it has 3 loops which are " >> > Loop at depth 1 containing: %17<header><exiting>,%19,%23<latch> >> > Loop at depth 1 containing: %8<header><exiting>,%10,%14<latch >> > Loop at depth 1 containing: %1<header><exiting>,%3,%5<latch> " > > > Then I tried to insert these loops into ls and the expected result is that > > there are 6 items in ls after the insertion. > > > But I got only 3. >> > So my question is why this happened? > > > The dense map uses the name of the loop to check if the element is in it? > > > Is there anything wrong during my code? >> > Looking forward to your answer. >> > Thank you >> > Sincerely, >> > Hanbing >> > _______________________________________________ > > > LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140829/faa98a57/attachment.html>
Hi, I tried to solve the problem by myself. And when I even got the densemap with 6 items, I still got 0 in another ModulePass by using the loopinfo derived in the new ModulePass. So if this means that when I use a loop in LoopInfo in a Function/ModulePass, I can't get the same loop object in another ModulePass. In other words, the loop objects in two ModulePasses are always different? Does anyone know something about it? Thank you Sincerely, Hanbing ----- Mail original -----> De: "Hanbing Li" <hanbing.li at inria.fr> > À: "John Criswell" <jtcriswel at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Envoyé: Vendredi 29 Août 2014 10:47:07 > Objet: Re: [LLVMdev] The problem of densemap and loop> Dear John,> First thing, the 3 loops in Densemap are all " Loop at depth 1 containing: > %1<header><exiting>,%3,%5<latch> " in the 3 functions.> The dense map is in a ImmutablePass. I got it in FunctionPass and tried > insert the information in this FunctionPass. So to turn the FunctionPass to > ModulePass may be a better idea?> Another interesting thing: if just before the insertion, I used "L -> > print(errs());" to print the Loop, there were 6 items in ls. BUT when I > tried to read it in a ModulePass, I can't get the correct result. > "> for (Module::iterator FI = M.begin(), E = M.end(); FI != E; ) { > F = FI++;> if (!F->hasName() && !F->isDeclaration()){} > else{> LoopInfo *LI = &getAnalysis<LoopInfo>(*F); > WCETInfo *WI = &getAnalysis<WCETInfo>(); //WI is the ImmutablePass which > contains the dense map> for(LoopInfo::iterator i=LI->begin(); i!=LI->end(); ++i) { > Loop *L = *i;> int lb=0; > lb=WI->outls(L); // the method: return ls.find(L)->second;> }> }> } "> Thank you> Sincerely,> Hanbing> ----- Mail original -----> > De: "John Criswell" <jtcriswel at gmail.com> > > > À: "Hanbing Li" <hanbing.li at inria.fr>, llvmdev at cs.uiuc.edu > > > Envoyé: Jeudi 28 Août 2014 18:59:52 > > > Objet: Re: [LLVMdev] The problem of densemap and loop >> > Dear Hanbing, >> > You haven't provided enough information to help diagnose the problem. It > > would help if you specified which 3 loops actually end up in the DenseMap. >> > One thing to check for is if your code is in a FunctionPass. A FunctionPass > > computes its results anew each time it is run on a function, and so it's > > possible that this is the cause of the problem. Similarly, the Loop objects > > for each function might be deleted and re-allocated for new Loop objects > > every time you run the LoopAnalysis on a new function. That would make it > > look like you only have three elements when, in fact, you've added six > > elements but three were deallocated. >> > Alternatively, you might have some something silly like making ls a local > > variable, so it gets destroyed each time you enter the function/method in > > which it appears. >> > However, these are just guesses. I'm not certain it can be diagnosed even > > if > > you do provide more information. >> > Regards, >> > John Criswell >> > On 8/28/14, 12:49 PM, Hanbing Li wrote: >> > > Hello, everyone, > > >> > > I created a dense map like this: DenseMap<Loop *, int> ls; > > > > > > And I have a module which contains 3 functions: > > > > > > function F and it has a loop which is " Loop at depth 1 containing: > > > %1<header><exiting>,%3,%5<latch> " > > > > > > function G and it has two loops which are " > > >> > > Loop at depth 1 containing: %8<header><exiting>,%10,%14<latch> > > >> > > Loop at depth 1 containing: %1<header><exiting>,%3,%5<latch> " > > > > > > function main and it has 3 loops which are " > > >> > > Loop at depth 1 containing: %17<header><exiting>,%19,%23<latch> > > >> > > Loop at depth 1 containing: %8<header><exiting>,%10,%14<latch > > >> > > Loop at depth 1 containing: %1<header><exiting>,%3,%5<latch> " > > > > > > Then I tried to insert these loops into ls and the expected result is > > > that > > > there are 6 items in ls after the insertion. > > > > > > But I got only 3. > > >> > > So my question is why this happened? > > > > > > The dense map uses the name of the loop to check if the element is in it? > > > > > > Is there anything wrong during my code? > > >> > > Looking forward to your answer. > > >> > > Thank you > > >> > > Sincerely, > > >> > > Hanbing > > >> > > _______________________________________________ > > > > > > LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140829/49b87491/attachment.html>
On 8/29/14, 8:52 AM, Hanbing Li wrote:> Hi, > > I tried to solve the problem by myself. And when I even got the > densemap with 6 items, I still got 0 in another ModulePass by using > the loopinfo derived in the new ModulePass. So if this means that when > I use a loop in LoopInfo in a Function/ModulePass, I can't get the > same loop object in another ModulePass. In other words, the loop > objects in two ModulePasses are always different?I think that the loop objects retrieved by two different ModulePasses would be different. The reason is that the PassManager tells the LoopInfo pass (a FunctionPass) to reinitialize itself every time it is run from a ModulePass. You therefore cannot call getAnalysis<LoopInfo>(F), grab a pointer to a Loop returned from the FunctionPass, and save it; the Loop object will be deleted (and its memory potentially reused) on the next call to getAnalysis. What you should do in your ModulePass is something like the following: for (every function F in the Module) { container box; for (every Loop L in the Function F) { Add L to box } for (every Loop L in box) { Do with loop whatever you are going to do with it } } If you really need to track all loops in all functions in a single data structure (and assuming that I'm correct that LoopInfo gets reinitialized), then I think there is something else you can do: instead of recording a pointer to the Loop object, record the basic block of the loop's header and the loop's nesting level. When you then need the Loop object, you run the LoopInfo pass on the function to which the basic block belongs and find the loop with the matching header basic block. As long as the CFG isn't modified in between the time you record the basic blocks and the time you look up the LoopInfo, this should work. Hope this helps, John Criswell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140829/052c7773/attachment.html>