Tobias von Koch
2012-Mar-13 16:39 UTC
[LLVMdev] How to keep FunctionPass analysis result alive in Module Pass?
Hi John & Fan, I hit the exact same problem today. I can confirm that Fan's observation of getting the *same* LoopInfo* from subsequent calls to getAnalysis<LoopInfo>(function) for *distinct* functions is indeed true. I was very surprised by this at first as well, but I think I've found an explanation - please anyone correct me if this is wrong: What you're getting from getAnalysis<>(function) is a reference to the function pass after it has been run on the specified function. While you can run a function pass on many different functions, there still exists only *one* instance of the pass itself. The only thing that changes between different calls to getAnalysis<LoopInfo>(F) is the analysis information held by the LoopInfo pass in its LoopInfoBase member. It gets released and overwritten on every call to LoopInfo::runOnFunction() - see the call to releaseMemory() right at the beginning. The idea of creating some sort of Map of Function* ----> LoopInfo* therefore won't work. It also doesn't make sense to keep Loop* pointers around after getAnalysis<LoopInfo>() has been called again because all that memory gets released (which is how I hit this problem)... Now, Fan, the practical consequence of this is that if you want to use LoopInfo in a ModulePass, you either have to do all your work that uses LoopInfo in between getAnalysis<LoopInfo> calls (if that's possible you're probably better off writing a FunctionPass in the first place) *OR* keep re-running getAnalysis<LoopInfo> which is very inefficient. I'd imagine the same goes for DominatorTree. In general, it would be nice if there was some logical separation between a *Function Pass *and the *Analysis Information *it produces. For LoopInfo, it's kind of there since all the data is in this LoopInfoBase object but there is no way of taking ownership of that... -- Tobias On Fri, Mar 9, 2012 at 22:34, John Criswell <criswell at illinois.edu> wrote:> On 3/9/12 4:28 PM, Fan Long wrote: > > Thank you for your quick reply. > > Actually I am using a std::map to map Function* to LoopInfo*, but that > does not help in this case. Each time I call > getAnalysis<llvm::LoopInfo>(*F), it returns the same instance of > llvm::LoopInfo, so the std::map is just mapping every function into the > same instance. It seems only the analysis result for the last function is > valid, because all the result for all previous functions are erased. > > > Just to make sure I understand: you are saying that every time you call > getAnalysis<LoopInfo>(), you get the *same* LoopInfo * regardless of > whether you call it on the same function or on a different function. Is > that correct? > > Getting the same LoopInfo * when you call getAnalysis<> on the same > function twice would not surprise me. Getting the same LoopInfo * when you > call getAnalysis on F1 and F2 where F1 and F2 are different functions would > surprise me greatly. > > > > The only workaround solution I have now is to copy all analysis result > out of the data structure of LoopInfo before I call next &getAnalysis(). > Because llvm::LoopInfo does not provide copy method, this will be very > dirty to do so. > > > Yes, that may be what you have to do. > > > -- John T. > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120313/d87f3053/attachment.html>
John Criswell
2012-Mar-13 16:41 UTC
[LLVMdev] How to keep FunctionPass analysis result alive in Module Pass?
On 3/13/12 11:39 AM, Tobias von Koch wrote:> Hi John & Fan, > > I hit the exact same problem today. I can confirm that Fan's > observation of getting the /*same*/ LoopInfo* from subsequent calls to > getAnalysis<LoopInfo>(function) for /*distinct*/ functions is indeed true. > > I was very surprised by this at first as well, but I think I've found > an explanation - please anyone correct me if this is wrong: > > What you're getting from getAnalysis<>(function) is a reference to the > function pass after it has been run on the specified function. While > you can run a function pass on many different functions, there still > exists only *one* instance of the pass itself. The only thing that > changes between different calls to getAnalysis<LoopInfo>(F) is the > analysis information held by the LoopInfo pass in its LoopInfoBase > member. It gets released and overwritten on every call to > LoopInfo::runOnFunction() - see the call to releaseMemory() right at > the beginning.That seems like a reasonable explanation.> > The idea of creating some sort of Map of Function* ----> LoopInfo* > therefore won't work. It also doesn't make sense to keep Loop* > pointers around after getAnalysis<LoopInfo>() has been called again > because all that memory gets released (which is how I hit this problem)... > > Now, Fan, the practical consequence of this is that if you want to use > LoopInfo in a ModulePass, you either have to do all your work that > uses LoopInfo in between getAnalysis<LoopInfo> calls (if that's > possible you're probably better off writing a FunctionPass in the > first place) /OR/ keep re-running getAnalysis<LoopInfo> which is very > inefficient. I'd imagine the same goes for DominatorTree. > > In general, it would be nice if there was some logical separation > between a /Function Pass /and the /Analysis Information /it produces. > For LoopInfo, it's kind of there since all the data is in this > LoopInfoBase object but there is no way of taking ownership of that...Can't you just copy the analysis results out of LoopInfo as Fan suggested? I would think that if you can query it, you can copy it. -- John T.> > -- Tobias > > > On Fri, Mar 9, 2012 at 22:34, John Criswell <criswell at illinois.edu > <mailto:criswell at illinois.edu>> wrote: > > On 3/9/12 4:28 PM, Fan Long wrote: >> Thank you for your quick reply. >> >> Actually I am using a std::map to map Function* to LoopInfo*, but >> that does not help in this case. Each time I call >> getAnalysis<llvm::LoopInfo>(*F), it returns the same instance of >> llvm::LoopInfo, so the std::map is just mapping every function >> into the same instance. It seems only the analysis result for the >> last function is valid, because all the result for all previous >> functions are erased. > > Just to make sure I understand: you are saying that every time you > call getAnalysis<LoopInfo>(), you get the *same* LoopInfo * > regardless of whether you call it on the same function or on a > different function. Is that correct? > > Getting the same LoopInfo * when you call getAnalysis<> on the > same function twice would not surprise me. Getting the same > LoopInfo * when you call getAnalysis on F1 and F2 where F1 and F2 > are different functions would surprise me greatly. > > >> >> The only workaround solution I have now is to copy all analysis >> result out of the data structure of LoopInfo before I call next >> &getAnalysis(). Because llvm::LoopInfo does not provide copy >> method, this will be very dirty to do so. > > Yes, that may be what you have to do. > > > -- John T. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120313/cc87a0c7/attachment.html>
Tobias von Koch
2012-Mar-13 17:03 UTC
[LLVMdev] How to keep FunctionPass analysis result alive in Module Pass?
Hi John, glad the explanation made sense :) On Tue, Mar 13, 2012 at 16:41, John Criswell <criswell at illinois.edu> wrote: [...]> Can't you just copy the analysis results out of LoopInfo as Fan > suggested? I would think that if you can query it, you can copy it. > >Well, LoopInfoBase has a private copy constructor (for good reasons) so you can't just copy the entire thing out. The same goes for the Loop class. At the end of the day, you just have to do the actual work already at this point which you were going to do with the analysis results later on. That's possible in my case (although it means I have to restructure my module pass quite a bit), but it might not always be? -- Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120313/fd13428c/attachment.html>
Seemingly Similar Threads
- [LLVMdev] How to keep FunctionPass analysis result alive in Module Pass?
- [LLVMdev] How to keep FunctionPass analysis result alive in Module Pass?
- [LLVMdev] How to keep FunctionPass analysis result alive in Module Pass?
- [LLVMdev] How to keep FunctionPass analysis result alive in Module Pass?
- [LLVMdev] How to keep FunctionPass analysis result alive in Module Pass?