search for: toolopt

...eed llvm-the-library with no static initializers will build with LLVM_NO_STATICINIT. In this mode, existing users of cl::opt will default to being optimized away as constant initializers, and those options will not be available for command line parsing. A new option class will need be defined, cl::toolopt. Initially, this will share the implementation and API with cl::opt. The only difference will be that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required for tool support can simply be type-renamed to toolopt. Since these are not defined in a library, their static initializers ar...

...static > initializers will build with LLVM_NO_STATICINIT. In this mode, existing > users of cl::opt will default to being optimized away as constant > initializers, and those options will not be available for command line > parsing. > > A new option class will need be defined, cl::toolopt. Initially, this will > share the implementation and API with cl::opt. The only difference will be > that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required > for tool support can simply be type-renamed to toolopt. Since these are not > defined in a library, their st...

...the-library with no static initializers will build with LLVM_NO_STATICINIT. In this mode, existing users of cl::opt will default to being optimized away as constant initializers, and those options will not be available for command line parsing. > > A new option class will need be defined, cl::toolopt. Initially, this will share the implementation and API with cl::opt. The only difference will be that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required for tool support can simply be type-renamed to toolopt. Since these are not defined in a library, their static initializers ar...

...ry with no static initializers will build with LLVM_NO_STATICINIT. In this mode, existing users of cl::opt will default to being optimized away as constant initializers, and those options will not be available for command line parsing. >> >> A new option class will need be defined, cl::toolopt. Initially, this will share the implementation and API with cl::opt. The only difference will be that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required for tool support can simply be type-renamed to toolopt. Since these are not defined in a library, their static initializers ar...

...tatic > initializers will build with LLVM_NO_STATICINIT. In this mode, > existing users of cl::opt will default to being optimized away as > constant initializers, and those options will not be available for > command line parsing. > > A new option class will need be defined, cl::toolopt. Initially, this > will share the implementation and API with cl::opt. The only > difference will be that cl::toolopt is immune to LLVM_NO_STATICINIT. > Options that are required for tool support can simply be > type-renamed to toolopt. Since these are not defined in a library, > the...

...the-library with no static initializers will build with LLVM_NO_STATICINIT. In this mode, existing users of cl::opt will default to being optimized away as constant initializers, and those options will not be available for command line parsing. > > A new option class will need be defined, cl::toolopt. Initially, this will share the implementation and API with cl::opt. The only difference will be that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required for tool support can simply be type-renamed to toolopt. Since these are not defined in a library, their static initializers ar...

...ry with no static initializers will build with LLVM_NO_STATICINIT. In this mode, existing users of cl::opt will default to being optimized away as constant initializers, and those options will not be available for command line parsing. >> >> A new option class will need be defined, cl::toolopt. Initially, this will share the implementation and API with cl::opt. The only difference will be that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required for tool support can simply be type-renamed to toolopt. Since these are not defined in a library, their static initializers ar...

...no static initializers will build with LLVM_NO_STATICINIT. In this mode, existing users of cl::opt will default to being optimized away as constant initializers, and those options will not be available for command line parsing. >>> >>> A new option class will need be defined, cl::toolopt. Initially, this will share the implementation and API with cl::opt. The only difference will be that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required for tool support can simply be type-renamed to toolopt. Since these are not defined in a library, their static initializers ar...

...zers will build with LLVM_NO_STATICINIT. In this mode, existing >> users of cl::opt will default to being optimized away as constant >> initializers, and those options will not be available for command line >> parsing. >> >> A new option class will need be defined, cl::toolopt. Initially, this >> will share the implementation and API with cl::opt. The only difference >> will be that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are >> required for tool support can simply be type-renamed to toolopt. Since >> these are not defined in a l...

...lization). > 5. There aren't enough options left not in those categories to motivate some kind of clever solution. I think that this is a great summary of the problem. Having cl::opt's compiled *out* of non-assert build by default makes a lot of sense to me, and having tool options use toolopt<> (or something) also makes perfect sense. If you're going to go and tackle pass-specific options, I think that we should consider changing the syntax and overall design of the command line options. We already have some manual name mangling/namespacification of options (e.g. -tail-dup-...

...;> 5. There aren't enough options left not in those categories to motivate some kind of clever solution. > > I think that this is a great summary of the problem. Having cl::opt's compiled *out* of non-assert build by default makes a lot of sense to me, and having tool options use toolopt<> (or something) also makes perfect sense. > > If you're going to go and tackle pass-specific options, I think that we should consider changing the syntax and overall design of the command line options. We already have some manual name mangling/namespacification of options (e.g....

...'t enough options left not in those categories to motivate > some kind of clever solution. > > > I think that this is a great summary of the problem. Having cl::opt's > compiled *out* of non-assert build by default makes a lot of sense to me, > and having tool options use toolopt<> (or something) also makes perfect > sense. > > If you're going to go and tackle pass-specific options, I think that we > should consider changing the syntax and overall design of the command line > options. We already have some manual name mangling/namespacification of...