[LLVMdev] The problem of densemap and loop

153 views
Skip to first unread message

Hanbing Li

unread,
Aug 28, 2014, 12:52:17 PM8/28/14
to llv...@cs.uiuc.edu
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

John Criswell

unread,
Aug 28, 2014, 1:05:45 PM8/28/14
to Hanbing Li, llv...@cs.uiuc.edu
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
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hanbing Li

unread,
Aug 29, 2014, 4:49:08 AM8/29/14
to John Criswell, llv...@cs.uiuc.edu
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


Hanbing Li

unread,
Aug 29, 2014, 8:54:57 AM8/29/14
to llv...@cs.uiuc.edu
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


John Criswell

unread,
Aug 29, 2014, 9:27:26 AM8/29/14
to Hanbing Li, llv...@cs.uiuc.edu
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

Hanbing Li

unread,
Aug 29, 2014, 11:15:34 AM8/29/14
to John Criswell, llv...@cs.uiuc.edu
Dear John,

Thank you for your answer.
The bad news is that I need to apply several optimizations between the store and read. So the CFG will be modified.
Anyway, I will find another way out.

Thank you very much!

Sincerely,

Hanbing


De: "John Criswell" <jtcr...@gmail.com>
À: "Hanbing Li" <hanbi...@inria.fr>, llv...@cs.uiuc.edu
Envoyé: Vendredi 29 Août 2014 15:24:52
Objet: Re: [LLVMdev] The problem of densemap and loop

Reply all
Reply to author
Forward
0 new messages