Hello all, I have 2 separate questions: 1, What are the differences between *LegacyPassManager* and *PassManager*? I see that *opt* uses the former most of the times while the latter is used via *PassBuilder* API when an user wants to build her own pipeline, but I have no idea why so. What to use and when to use it is not clear to me. 2, I've asked this question once but have had no answer, so I'm gonna revive it here: in *opt*, the *verify-each* mode is only activated when we provide a pass name or a pipeline (list of pass names). I guess this is intended, but I expect that *verify-each* to insert *Verifier* to the whole pipeline after each optimization pass, even when I pass -O1/2/3/s/z to *opt*. And I assume others do expect the same thing. The 2nd question lead me to another idea: if we really want to make *verify-each* to work on any pipeline (not only user-provided ones), and we'll soon have a *debugify-each* option, should we refactor the code to have a *apply-after-each=pass-name* option that automatically inserts *pass-name *to the pipeline after each optimization pass? We can even replace *print-after-all* option with *apply-after-each=PrintModulePassWrapper *for example? Thank you all, Son Tuan Vu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180417/9be9daca/attachment.html>
Hi Son, I have an answer to your first question: 1, What are the differences between *LegacyPassManager* and *PassManager*?> I see that *opt* uses the former most of the times while the latter is > used via *PassBuilder* API when an user wants to build her own pipeline, > but I have no idea why so. What to use and when to use it is not clear to > me. >PassManager is the result of a long going effort to replace the default pass manager of opt and clang. Here's the original RFC containing the motivation: http://lists.llvm.org/pipermail/llvm-dev/2012-July/051643.html LegacyPassManager is currently still the default, but we are really close to switching over the the new one. Both opt and clang have switches to enable the new one, by calling `opt -passes="...."` or `clang -fexperimental-new-pass-manager`. PassBuilder is essentially a big factory to produce PassManager and AnalysisManager objects for the passes and analyses included in core LLVM. If you develop analyses and passes, I'd suggest doing so against the new PM, especially if you plan on upstreaming your work. Cheers, Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180417/7e251243/attachment.html>
Hi Philip, Thank you for your reply. So what would be the right way/API to write out-of-tree pass? I've been using *PassManagerBuilder*, which requires a callback refering to *legacy::PassManagerBase*, so I guess this will be no longer the good way to go? Son Tuan Vu On Tue, Apr 17, 2018 at 6:06 PM, Philip Pfaffe <philip.pfaffe at gmail.com> wrote:> Hi Son, > > I have an answer to your first question: > > 1, What are the differences between *LegacyPassManager* and *PassManager*? >> I see that *opt* uses the former most of the times while the latter is >> used via *PassBuilder* API when an user wants to build her own pipeline, >> but I have no idea why so. What to use and when to use it is not clear to >> me. >> > PassManager is the result of a long going effort to replace the default > pass manager of opt and clang. Here's the original RFC containing the > motivation: http://lists.llvm.org/pipermail/llvm-dev/2012-July/051643.html > > LegacyPassManager is currently still the default, but we are really close > to switching over the the new one. Both opt and clang have switches to > enable the new one, by calling `opt -passes="...."` or `clang > -fexperimental-new-pass-manager`. PassBuilder is essentially a big > factory to produce PassManager and AnalysisManager objects for the passes > and analyses included in core LLVM. If you develop analyses and passes, I'd > suggest doing so against the new PM, especially if you plan on upstreaming > your work. > > Cheers, > Philip >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180418/df2fa3b6/attachment.html>