[LLVMdev] How to keep FunctionPass analysis result alive in Module Pass?

[John Criswell]

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>