[LLVMdev] Add a new information and preserve it in LLVM

John Criswell criswell at illinois.edu
Mon Apr 7 14:05:27 PDT 2014


On 4/7/14 11:08 AM, Hanbing Li wrote:
> Hi John,
>
> Thank you for your answer. I tried ImmutablePasses, while the problem 
> came again.
> Because the W need some information like loopinfo, so I need LoopInfo 
> *LI = &getAnalysis<LoopInfo>(F); in this ImmutablePasses, and Function 
> or Module are needed.
> I didn't find a way to get the Module or Function in ImmutablePasses.

It sounds like your pass is not a simple container which other passes 
use to store information.  It sounds like your pass is doing actual 
analysis work.  If that is the case, then you should probably use a 
ModulePass instead of an ImmutablePass.  By making your pass a 
ModulePass, the PassManager can invalidate and re-run your pass whenever 
an optimization pass changes the IR in a way that invalidates your 
analysis pass's results.

>
> So, 1, can I use LoopInfo *LI = &getAnalysis<LoopInfo>(F); in 
> ImmutablePasses?
> 2, is there a method to get the Module in ImmutablePasses?

You might be able to do that in an ImmutablePass, but I'd recommend 
using a ModulePass.

Regards,

John Criswell

>
> Thank you!
>
> Sincerely,
>
> Hanbing
>
> ------------------------------------------------------------------------
>
>     *De: *"John Criswell" <criswell at illinois.edu>
>     *À: *"Hanbing Li" <hanbing.li at inria.fr>, llvmdev at cs.uiuc.edu
>     *Envoyé: *Samedi 5 Avril 2014 00:27:13
>     *Objet: *Re: [LLVMdev] Add a new information and preserve it in LLVM
>
>     On 4/4/14 3:02 PM, Hanbing Li wrote:
>
>         Hello,
>
>
>         I am trying to add some thing into LLVM, while I encountered
>         some problems.
>
>
>         So my situation is that I have some information W, some
>         transform passes may change it, after these passes, I need the
>         new W. What I did is to create an analysis pass similar to
>         scalar-evolution or loopinfo, I can get the information by
>         using getAnalysis<W>(); and preserve this information W by
>         using AU.addPreserved<W>();. Then the problem came, for the
>         module pass, the information can’t be preserved. (I found
>         this: To the best of my knowledge, the LLVM pass manager never
>         preserves a FunctionPass analysis that is requested by a
>         ModulePass; every time you call getAnalysis for a function,
>         the FunctionPass is re-run.
>         http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048139.html)
>         So this means that I can’t update W when some module passes
>         changed it?
>
>
>         My questions are:
>
>         1, Module pass really can’t preserve the W?
>
>
>     If W is a FunctionPass, then I believe you are correct: a
>     ModulePass will re-run the FunctionPass every time it uses the
>     FunctionPass.
>
>     I get the impression that you're using the PassManager
>     infrastructure improperly, and that is probably why you're not
>     getting the results you want.
>
>     First, the ability to preserve a pass's results with
>     addPreserved<W>() is an optimization.  A FunctionPass or
>     ModulePass() that analyzes the LLVM IR should work whether it is
>     run one time or a hundred times.  The addPreserved<>()
>     functionality is only there so that the LLVM compiler can cache
>     the results of analysis passes for efficiency.
>
>     Second, the way to fix your problem depends on what you want to
>     do.  If you want pass W to analyze the LLVM IR of a program and
>     cache its results (because the analysis it does is expensive),
>     then make it a ModulePass.  That way, other ModulePass'es can
>     update and preserve its results.
>
>     If you are just using W as a container in which to record
>     information that transform passes are doing, then you might want
>     to make W an ImmutablePass.  ImmutablePasses are only run once and
>     are never invalidated; other passes can use them to record
>     information about what they do.  ImmutablePasses, I think, were
>     not really designed for this purpose, but they'll get the job done.
>
>     Regards,
>
>     John Criswell
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140407/0986839d/attachment.html>


More information about the llvm-dev mailing list