<div dir="ltr"><div>Hi,</div><div><br></div><div>So, does this mean that in legacy pass manager, when I run:</div><div>PM.add( someFunctionPass() )     // PM is modulePassManager<br></div><div>it creates FunctionPassManager, runs the function pass,destroys the functionPassManager and returns control to modulePassManager?</div><div><br></div><div>Also, you have said that this wasn't the primary reason for the introduction of the new pass manager. But then is this one of the reasons?</div><div><br></div><div>Regards</div><div>Sushant<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 10, 2020 at 2:28 AM Michael Kruse <<a href="mailto:llvmdev@meinersbur.de">llvmdev@meinersbur.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In the old pass manager a coarser-grain pass cannot depend on a<br>
fine-grain pass (or analysis). In this case, the coarser-grain is the<br>
Inliner (CallGraphSCCPass) and the finer a FunctionPass. The reason is<br>
that the finer-grain pass has its own "pass manager", i.e. it runs all<br>
the passes and analysis (in that pass manager) on one function, frees<br>
them, and continues with the next function until all functions in the<br>
module have been process and only then gives control back to the<br>
coarser-grain pass manger. That is, at this point, all the<br>
FunctionPass analyses has been and is not available anymore.<br>
<br>
There is a workaround for ModulePasses using FunctionPasses: The<br>
ModulePassManager would run the FunctionPass on the requested function<br>
(without the FunctionPassManager). But it will only hold the result<br>
for one Function; if you request the analysis for a different<br>
function, it will free the previous one.<br>
<br>
This is not the primary reason for the introduction of the new pass<br>
manager: The legacy pass manager could have been modified to not free<br>
all analyses, but like the NPM keep a global map of all analyses run<br>
so far that have not been invalidated yet.<br>
<br>
Michael<br>
<br>
<br>
<br>
Am Mo., 9. Nov. 2020 um 05:28 Uhr schrieb sushant gokhale via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>:<br>
><br>
> Hi,<br>
><br>
> In following link:<br>
> <a href="https://www.youtube.com/watch?reload=9&v=6X12D46sRFw" rel="noreferrer" target="_blank">https://www.youtube.com/watch?reload=9&v=6X12D46sRFw</a><br>
><br>
> They have specified that the inliner can't use DomTree/LoopInfo/MemorySSA analysis.<br>
> 1. What's the reason for this?<br>
> 2. Why can't we do it using getAnalysisUsage() construct?<br>
> 3. Can inline use this information in the new Pass Manager?<br>
> 4. What all information can we derive from DomTree to be of help to inliner?<br>
><br>
> Regards<br>
> Sushant<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>