[LLVMdev] The problem of densemap and loop

[John Criswell]

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>