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

[Maxthon Chan]

Dropping another idea: how about some Compiler-as-a-service paradigm?

That is, instead of statically initialise them, create a class for those internal state and allowing pushing and pooping them. The only remaining statically initialised object will be the state stack, whose statical initialising is reasonable.

On Sep 18, 2013, at 5:25, Andrew Trick <atrick at apple.com> wrote:

> 
> On Sep 17, 2013, at 11:25 AM, Shankar Easwaran <shankare at codeaurora.org> wrote:
> 
>> Isnt all the command line options only relevant to the driver, so if all the command line options are migrated to the driver, the library will be free from static initializers.
>> 
>> Doesnt this make it more cleaner ?
> 
> Yes, but less convenient for developing experimental passes. I think we want to move in this direction, as I explained to Eric. We don’t have a good framework for tool options, and solving that problem will take a lot more time than what I’ve proposed so far.
> 
> -Andy
> 
>> On 9/17/2013 12:10 PM, Andrew Trick 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
>> 
>> 
>> -- 
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
>> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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