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

[Chris Bieneman]

> On Aug 18, 2014, at 3:09 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
>> Some passes take options directly in the constructor. For example
>> 
>> Inliner::Inliner(char &ID, int Threshold, bool InsertLifetime)
>> 
>> Maybe we could just say that there are two different types of options.
>> The ones we want to expose to users and the ones which we use for
>> testing llvm itself. The options we want to expose should be just
>> constructor arguments. With that distinction we should be able to just
>> not use the options added by  cl::OptionRegistry::CreateOption unless
>> cl::ParseCommandLineOptions is called. WebKit like clients would just
>> not call cl::ParseCommandLineOptions. Would that work?
>> 
>> 
>> This is actually how some of our internal clients are already working. There
>> are a few caveats with this approach:
>> 
>> (1) You can’t allow the pass manager to allocate your passes for you,
>> because those passes only read from cl::opts
> 
> You mean PassManagerBuilder, right?

Yes.

> 
>> (2) Not all of our passes have constructors for overriding their cl::opts
>> (the legacy Scalarizer is one)
>> 
>> I think it would in general be cleaner to provide a way for library clients
>> to use cl::opts without being forced to parse a command line.
> 
> I guess it really depends on how many options there are that we want
> to expose via an API. I have the impression that there are few, which
> would make changing the constructors and PassManagerBuilder better.
> 
> If there is a large number of options that we want to expose, then I
> can see the value of having a llvm "configuration object" that is
> passed around and is queried by the passes. If we do go down this
> road, we should change passes like the inliner to use the
> configuration object instead of constructor options. We should also
> drop the "cl" from the names if it is not going to be handling command
> lines :-)

I’m curious if Tom Stellard or Filip Pizlo have any input on this as they are more directly involved on the client side.

I do agree that we should ultimately drop the cl namespace if we’re going in this direction.

-Chris

> 
> Cheers,
> Rafael