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

[Andrew Trick]

On Sep 17, 2013, at 10:25 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
>> 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..."), );
>> }
> 
> Sounds good to me.
> 
> Will this make it safe again to use -backend-option in Clang? [Not saying that we *want* to do that, but that's a separate matter].
> 
> Regardless of the answer to that question, it might make sense for multiple target backends to register options with the same name (currently, for example, both the X86 and PPC backends have options to force the use of a base pointer, and they need to have different names), it would be nice if that could be cleaned up as part of this.

The only solution I have for this is to raise both options into the target-independent API. Currently, that means adding it to TargetOptions and moving the flag to CommandLineFlags.h. I feel like the way to improve this is by redesigning TargetOptions to be less ad-hoc. It would be nice to define an option string in one place and allow the option to be overridden as a function attribute or command line -mllvm option. We should probably have a declarative option syntax for this like clang.

-Andy

> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130917/ab9132de/attachment.html>