[LLVMdev] [RFC] Removing static initializers for command line options

Chris Bieneman beanz at apple.com
Tue Aug 19 11:43:06 PDT 2014


> On Aug 19, 2014, at 11:09 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> On 19 August 2014 13:47, Chris Bieneman <beanz at apple.com> wrote:
>> I’d like to propose moving forward with the first phase of my proposal to
>> make the cl::opt structures owned and eliminate global option storage.
> 
> For now, please eliminate only the static constructor and leave the
> storage. Since it seems only a few options that need to be exposed by
> non-command line APIs, we might be able to avoid the need for a
> cl::OptionRegistry::GetValue.

I strongly feel this is the wrong decision. If you have a single process using two LLVM clients (say WebKit and Mesa), and they both are using an opt pass with different settings. If the storage is global this will not work.

> 
>> I’d
>> also like to add to it that when updating passes I will ensure that each
>> pass that has cl::opts also has a default constructor, an overridden
>> constructor to populate each option, and the corresponding factory methods
>> for the C API.
> 
> And *please* don't add anything to the C api unless someone has a real
> need for that particular interface and there is a good discussion on
> the review thread about it. The C api has more backwards compatibility
> promises, which makes it incredibly painful :-(
> 
> Even the C++ api is not free, so I would also only modify a pass
> constructor if someone wants to pass that option for something other
> then llvm development or testing. For that command lines are a
> perfectly reasonable solution.

I can agree with all of this.

-Chris

> 
>> Does this sound reasonable for a first step?
> 
> Removing the static constructors does.
> 
> Cheers,
> Rafael





More information about the llvm-dev mailing list