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(); and preserve this information W by using AU.addPreserved();. 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?
2, If it’s real, why and how can I fix this? If it’s not, what should I do to keep the information W?
3, The way of using an analysis pass to keep the information of W is suitable? Any other better solution?
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() 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
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(F); in this ImmutablePasses, and Function or Module are needed.
I didn’t find a way to get the Module or Function in ImmutablePasses.
So, 1, can I use LoopInfo *LI = &getAnalysis(F); in ImmutablePasses?
2, is there a method to get the Module 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. You might be able to do that in an ImmutablePass, but I’d recommend using a ModulePass. Regards, John Criswell
“The addPreserved<>() functionality is only there so that the LLVM compiler can cache the results of analysis passes for efficiency.”
The addPreserved() function only tells the compiler to cache it? I was under the impression from the code that it was an indication that a transformation pass doesn’t invalidate whatever analysis pass it says it preserves. If it is only an indication that the compiler should cache it, how does the compiler know if a particular analysis pass should be re-run?
I’m going through the LegacyPassManager now and there definitely are some parts I don’t understand what they are for.