Andrzej Warzynski via llvm-dev
2019-Sep-08 16:20 UTC
[llvm-dev] New PM, opt and command line options
Hi all, I'm porting some LLVM plugins to the new pass manager and I've noticed that the command line options are no longer registered when using `-load-pass-plugin` (the new PM flag) to load the plugins in opt. Everything is back to normal when loading via `-load` (the legacy PM). For example, given this CL option: static cl::opt<bool> SomeFlat("some-flag", cl::init(false), cl::desc("set some flag")); I can see that it's being registered: opt -load MyPlugin -help | grep some-flag -some-flag - set some flag However, this returns nothing: opt -load-pass-plugin -help | grep some-flag Am I missing something obvious? Or is that `by design`? -Andrzej
Min-Yih Hsu via llvm-dev
2019-Sep-08 18:30 UTC
[llvm-dev] New PM, opt and command line options
Hi, I think it’s just a matter of initialization order. In the old PM, pass plugins are loaded by “-load” options, which is defined in Support/PluginLoader. In Support/PluginLoader.h we can found that it has a custom command line options parser: `cl::opt<PluginLoader, false, cl::parser<std::string> >`. Which would call `PluginLoader::operator=` later, which is the place where it load the dynamic libraries. All the registrations mentioned previously happened before the `main` function of opt, because the `cl::opt<>` is defined as a global static variable. And because it happened before the `main` function, by the time `cl::ParseCommandLineOptions` is called (inside the `main` function of opt), the command line subsystem already knew all of the option information defined in your plugin. Therefore it can display a correct `-help` text. On the other hand, all of the logic for new PM in opt is defined in tools/opt/NewPMDriver.cpp. In there, dynamic libraries will not be loaded until `PassPlugin::Load(…)` is called inside the `llvm::runPassPipeline` function, which is invoked later than `cl::ParseCommandLineOptions` in the `main` function. In another word, the options in your plugin are not displayed because your dynamic plugin library is not even loaded when the command line subsystem is trying to display the help text. B.R. - Min> On Sep 8, 2019, at 12:20 PM, Andrzej Warzynski via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > I'm porting some LLVM plugins to the new pass manager and I've noticed > that the command line options are no longer registered when using > `-load-pass-plugin` (the new PM flag) to load the plugins in opt. > Everything is back to normal when loading via `-load` (the legacy PM). > > For example, given this CL option: > > static cl::opt<bool> SomeFlat("some-flag", cl::init(false), > cl::desc("set some flag")); > > I can see that it's being registered: > > opt -load MyPlugin -help | grep some-flag > -some-flag - set some flag > > However, this returns nothing: > > opt -load-pass-plugin -help | grep some-flag > > > Am I missing something obvious? Or is that `by design`? > > -Andrzej > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Andrzej Warzynski via llvm-dev
2019-Sep-09 08:01 UTC
[llvm-dev] New PM, opt and command line options
This is a very detailed and clear explanation - thank you Min! -Andrzej On 08/09/2019 19:30, Min-Yih Hsu wrote:> Hi, > > I think it’s just a matter of initialization order. > > In the old PM, pass plugins are loaded by “-load” options, which is defined in Support/PluginLoader. > In Support/PluginLoader.h we can found that it has a custom command line options parser: > `cl::opt<PluginLoader, false, cl::parser<std::string> >`. Which would call `PluginLoader::operator=` later, which is the place where it load the dynamic libraries. All the registrations mentioned previously happened before the `main` function of opt, because the `cl::opt<>` is defined as a global static variable. And because it happened before the `main` function, by the time `cl::ParseCommandLineOptions` is called (inside the `main` function of opt), the command line subsystem already knew all of the option information defined in your plugin. Therefore it can display a correct `-help` text. > > On the other hand, all of the logic for new PM in opt is defined in tools/opt/NewPMDriver.cpp. In there, dynamic libraries will not be loaded until `PassPlugin::Load(…)` is called inside the `llvm::runPassPipeline` function, which is invoked later than `cl::ParseCommandLineOptions` in the `main` function. > In another word, the options in your plugin are not displayed because your dynamic plugin library is not even loaded when the command line subsystem is trying to display the help text. > > B.R. > - Min > >> On Sep 8, 2019, at 12:20 PM, Andrzej Warzynski via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> I'm porting some LLVM plugins to the new pass manager and I've noticed >> that the command line options are no longer registered when using >> `-load-pass-plugin` (the new PM flag) to load the plugins in opt. >> Everything is back to normal when loading via `-load` (the legacy PM). >> >> For example, given this CL option: >> >> static cl::opt<bool> SomeFlat("some-flag", cl::init(false), >> cl::desc("set some flag")); >> >> I can see that it's being registered: >> >> opt -load MyPlugin -help | grep some-flag >> -some-flag - set some flag >> >> However, this returns nothing: >> >> opt -load-pass-plugin -help | grep some-flag >> >> >> Am I missing something obvious? Or is that `by design`? >> >> -Andrzej >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
Reasonably Related Threads
- Adding custom callback function before/after passes
- How to debug passes
- Adding custom callback function before/after passes
- [flang-dev] [cfe-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM
- [cfe-dev] [flang-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM