Hi John & Fan,<div><br></div><div>I hit the exact same problem today. I can confirm that Fan's observation of getting the <i><b>same</b></i> LoopInfo* from subsequent calls to getAnalysis<LoopInfo>(function) for <i><b>distinct</b></i> functions is indeed true.</div>

<div><br></div><div>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:</div><div><br></div><div>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 <b>one</b> 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.</div>

<div><br></div><div>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)...</div>

<div><br></div><div>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) <i>OR</i> keep re-running getAnalysis<LoopInfo> which is very inefficient. I'd imagine the same goes for DominatorTree.</div>

<div><br></div><div>In general, it would be nice if there was some logical separation between a <i>Function Pass </i>and the <i>Analysis Information </i>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...</div>
<div><br></div><div>-- Tobias</div><div><br></div><div><br><div class="gmail_quote">On Fri, Mar 9, 2012 at 22:34, John Criswell <span dir="ltr"><<a href="mailto:criswell@illinois.edu" target="_blank">criswell@illinois.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div>
    On 3/9/12 4:28 PM, Fan Long wrote:
    <blockquote type="cite">Thank you for your quick reply.
      <div><br>
      </div>
      <div>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.</div>
    </blockquote>
    <br></div>
    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?<br>
    <br>
    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.<div><br>
    <br>
    <blockquote type="cite">
      <div><br>
      </div>
      <div>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.</div>
    </blockquote>
    <br></div>
    Yes, that may be what you have to do.<div><div><br>
    <br>
    -- John T.<br><br></div></div></div></blockquote></div></div>