search for: parsecommandline

I need to use LLVM's command line utilities for parsing command line in an online compiling mode. Since multiple program may be compiled online with same or different command line options, the options states need to be saved and restored. I found it is hard to save and restore opt (options), given that opt are defined with C++ templates, and options are registered implicitly through class

I need to use LLVM's command line utilities for parsing command line in an online compiling mode. Since multiple program may be compiled online with same or different command line options, the options states need to be saved and restored. I found it is hard to save and restore opt (options), given that opt are defined with C++ templates, and options are registered implicitly through class

...ids static initialization. One easy pattern to follow is to register the option during pass initialization with all the convenient flags and parameters, but refer to a globally defined option storage that enforces the singleton and provides visibility. As long as pass initialization happens before parseCommandLine, usage should be consistent. Strawman: cl::optval<bool> MyOption; // Just the storage, no initialization. MyPass() { // Only registers an option with the same optval once. Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden, cl::desc("Descriptive...

Wait, I have a terrible idea. Why don't we roll our own .init_array style appending section? I think we can make this work for all toolchains we support. We'd have something like: struct PODOptData { const char *FlagName; ... // Common POD stuff, can be initialized at ParseCommandLine time. }; LLVM_SECTION(".llvmopt") PODOptData OptionRegisterer = { "foo_flag", ... }; I know the COFF magic to get the section bounds to form an array, and I know it exists for ELF, but I don't know how to do it on Darwin. On Tue, Sep 17, 2013 at 10:10 AM, Andrew Trick &...

...the tool level instead. This seems like something we want to do anyway, but I’m not proposing anything definite yet (I’m happy as long we’re moving in that direction). We may want to raise some options all the way to function attributes. > b) "As long as pass initialization happens before parseCommandLine, > usage should be consistent." I'm thinking this isn't going to work for > the opt tool at least :) > > Thoughts? I think all the standard passes will be initialized up front. The problem would be with plugins using -load, but I fail to see how that can work with -help t...

...ire to remove command line options and having them be initialized as part of the pass would be general goodness. However, a few possible issues: a) a number of command line options aren't really connected to passes per-se (backend options) b) "As long as pass initialization happens before parseCommandLine, usage should be consistent." I'm thinking this isn't going to work for the opt tool at least :) Thoughts? -eric On Tue, Sep 17, 2013 at 10:10 AM, Andrew Trick <atrick at apple.com> wrote: > LLVM's internal command line library needs to evolve. We have an immediate nee...

...We may want to raise some options all the way to function attributes. > something like this. I think this is the way to go. I'm not sure how it would look other than passing option structs into a context, but that might work? >> b) "As long as pass initialization happens before parseCommandLine, >> usage should be consistent." I'm thinking this isn't going to work for >> the opt tool at least :) >> >> Thoughts? > > I think all the standard passes will be initialized up front. The problem would be with plugins using -load, but I fail to see how th...

Is there a way to set how aggressive the inliner pass (createFunctionInliningPass) without going through the command line interface? Is there any reason InlineLimit isn't an argument to the createFunctionInliningPass function? Thanks, Robert

On Mon, 7 Jan 2008, Robert Zeh wrote: > Is there a way to set how aggressive the inliner pass > (createFunctionInliningPass) without going through the command line > interface? Nope. Well, you could call cl::ParseCommandLine yourself (passing in a static array) like llvm-gcc does, but other than that "no". > Is there any reason InlineLimit isn't an argument to the > createFunctionInliningPass function? Nope :). That would be a great enhancement. -Chris -- http://nondot.org/sabre/ http://llvm....

Hey Andy > One easy pattern to follow is to register the option during pass initialization with all the convenient flags and parameters, but refer to a globally defined option storage that enforces the singleton and provides visibility. As long as pass initialization happens before parseCommandLine, usage should be consistent. > > Strawman: > > cl::optval<bool> MyOption; // Just the storage, no initialization. > > MyPass() { > // Only registers an option with the same optval once. > Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden, >...

...c initialization. > > One easy pattern to follow is to register the option during pass initialization with all the convenient flags and parameters, but refer to a globally defined option storage that enforces the singleton and provides visibility. As long as pass initialization happens before parseCommandLine, usage should be consistent. > > Strawman: > > cl::optval<bool> MyOption; // Just the storage, no initialization. > > MyPass() { > // Only registers an option with the same optval once. > Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden, >...

...; > One easy pattern to follow is to register the option during pass > initialization with all the convenient flags and parameters, but > refer to a globally defined option storage that enforces the > singleton and provides visibility. As long as pass initialization > happens before parseCommandLine, usage should be consistent. > > Strawman: > > cl::optval<bool> MyOption; // Just the storage, no initialization. > > MyPass() { > // Only registers an option with the same optval once. > Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden, >...

...ization. >> >> One easy pattern to follow is to register the option during pass initialization with all the convenient flags and parameters, but refer to a globally defined option storage that enforces the singleton and provides visibility. As long as pass initialization happens before parseCommandLine, usage should be consistent. >> >> Strawman: >> >> cl::optval<bool> MyOption; // Just the storage, no initialization. >> >> MyPass() { >> // Only registers an option with the same optval once. >> Option cl::registerOpt(MyOption, cl::init(...

...ert On Jan 8, 2008, at 3:26 PM, Chris Lattner wrote: > On Mon, 7 Jan 2008, Robert Zeh wrote: >> Is there a way to set how aggressive the inliner pass >> (createFunctionInliningPass) without going through the command line >> interface? > > Nope. Well, you could call cl::ParseCommandLine yourself (passing > in a > static array) like llvm-gcc does, but other than that "no". > >> Is there any reason InlineLimit isn't an argument to the >> createFunctionInliningPass function? > > Nope :). That would be a great enhancement. > > -Chris &...

...ost everything else, the implicitly initialized "feature" of llvm::cl isn't all that useful, and is in some cases actively harmful. - Daniel We'd have something like: > > struct PODOptData { > const char *FlagName; > ... // Common POD stuff, can be initialized at ParseCommandLine time. > }; > > LLVM_SECTION(".llvmopt") > PODOptData OptionRegisterer = { "foo_flag", ... }; > > I know the COFF magic to get the section bounds to form an array, and I > know it exists for ELF, but I don't know how to do it on Darwin. > > > &gt...

...and line options? >> 3. Where should the command line options or module/function attributes be stored once they are read out from the IR? >> >> The short description of the approach I took in my patch is that command line options that are important to codegen are collected by cl::ParseCommandLineOptions, written to the bitcode as function or module attributes, and read out directly by the optimization passes that need them. cl::opt options are replaced with CodeGenOpt options (subclass of cl::opt), which are needed only to parse the command line and provide the default value when the corres...