The problem of densemap and loop

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,%3,%5”
function G and it has two loops which are "

Loop at depth 1 containing: %8,%10,%14

Loop at depth 1 containing: %1,%3,%5

"
function main and it has 3 loops which are "

Loop at depth 1 containing: %17,%19,%23

Loop at depth 1 containing: %8,%10,%14<latch

Loop at depth 1 containing: %1,%3,%5

"
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

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

Dear John,

First thing, the 3 loops in Densemap are all “Loop at depth 1 containing: %1,%3,%5” 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(*F);
WCETInfo *WI = &getAnalysis(); //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

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

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(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

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