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

Tobias von Koch tobias.von.koch at gmail.com
Tue Mar 13 09:39:14 PDT 2012


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>


More information about the llvm-dev mailing list