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

[Andrew Trick]

On Sep 17, 2013, at 10:18 AM, Pete Cooper <peter_cooper at apple.com> wrote:

> 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,
>>                        cl::desc("Descriptive string..."), );
>> }
> Given Chandler's upcoming work on the pass manager, should we assume that multithreaded passes are a future possibility.  If so, would the above variable need to be static inside the constructor, or is there some better way to initialize it only once?  Or perhaps cl options just don't make any sense in a multithreaded context and you can ignore my ramblings.


Thanks for giving me a chance to clarify and fix a typo.

Normally, you wouldn’t need to capture the Option object at all, just register it:

MyPass() {
  cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
                       cl::desc("Descriptive string..."), );
}

The globally defined option storage will have an initialized flag and registerOpt will do a CAS on that for thread safety. Subsequent calls to registerOpt with the same option storage will do nothing.

Now, we might want to capture the option object as such:

MyPass() {
  Option &MyOpt = cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
                                  cl::desc("Descriptive string..."), );
}

Subsequent calls to registerOpt will just return the existing Option object.

-Andy

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