[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