CallSite in innermost loop

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

CallSite in innermost loop

Pankaj Gode
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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: CallSite in innermost loop

Devang Patel

On Nov 16, 2011, at 2:43 AM, Pankaj Gode wrote:

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?


PassManager not only schedules passes, it also 
- manages memory
- ensures that analysis info is valid at the point of use
- eliminates redundant calculation of analysis
- automatically schedule other required passes
- takes responsibility of walking program construct. For example, a LoopPass does not need to worry about how to walk loop nest. A FunctionPass does not worry about in which order the functions are processed. 

Right now, CallGraph pass manager is not equipped to satisfy these requirements at loop level. You could certainly extend the PassManager, but it is not structured and designed to support such scenarios.

That does not mean you can not use LoopInfo in your pass. It means, you'll have 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: CallSite in innermost loop

Pankaj Gode
Thanks for giving me more insight into this.
 
I could use the approach of using LoopInfo in my pass. I have taken care of the memory management and validated the information as well.  LoopInfo has made the task a lot simpler.
 
In order to check whether the function basic block is a innermost loop, I am doing following:
LoopInfo LI;
DominatorTree DT;
DT.DT->recalculate(*F);
LI.getBase().Calculate( DT.getBase() ) ;
 
//.. some code
//BB is a basic block in some function.
if( Loop *L = LI.getLoopFor( BB) ) {
  //loop with no subloops is innermost.
  if( L->getSubLoops().empty() )  
    break; //is innermost loop
}
 
Regards,
Pankaj

From: Devang Patel <[hidden email]>
To: Pankaj Gode <[hidden email]>
Cc: llvm Developers <[hidden email]>
Sent: Wednesday, November 16, 2011 11:15 PM
Subject: Re: [LLVMdev] CallSite in innermost loop


On Nov 16, 2011, at 2:43 AM, Pankaj Gode wrote:

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?


PassManager not only schedules passes, it also 
- manages memory
- ensures that analysis info is valid at the point of use
- eliminates redundant calculation of analysis
- automatically schedule other required passes
- takes responsibility of walking program construct. For example, a LoopPass does not need to worry about how to walk loop nest. A FunctionPass does not worry about in which order the functions are processed. 

Right now, CallGraph pass manager is not equipped to satisfy these requirements at loop level. You could certainly extend the PassManager, but it is not structured and designed to support such scenarios.

That does not mean you can not use LoopInfo in your pass. It means, you'll have 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



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev