[LLVMdev] [RFC] Internal command line options should not be statically initialized.

[Eric Christopher]

Hi Andy,

I definitely agree with the desire 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 need to build LLVM as a library free of static initializers, but before brute-force fixing this problem, I'd like outline the incremental steps that will lead to a desirable long term solution. We want infrastructure in place to provide an evolutionary path.
>
> In the near term, clients who need 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 are irrelevant.
>
> Eventually, we would like to eliminate the special LLVM_NO_STATICINIT build mode. This can be done by making the -Asserts build just as strict. In the meantime, we would like to run as many unit tests as possible with LLVM_NO_STATICINIT builds. This will be solved by gradually moving cl::opt definitions buried within LLVM libraries to to a new pattern that avoids 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 string..."), );
> }
>
> -Andy
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev