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

[Chris Bieneman]

> On Aug 19, 2014, at 3:10 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
>> There are two reasons this doesn’t work:
>> 
>> (1) Cases where I might want to set a debug variable for the WebKit JIT but not for Mesa - if the option storage is global it will get overwritten for all users
> 
> This really comes up? Really, we are not talking -O2/-O3 or inlining
> thresholds. We are talking things like lcr-max-depth being needed for
> a debugging session.

I’ve toggled on SROA's "sroa-random-shuffle-slices” before for testing, I've played with InstCombine’s "enable-double-float-shrink”, so it does (although admittedly not terribly often).

> 
>> (2) cl::ParseCommandLineOptions today is C++ API, WebKit restricts itself to the C API, so at the least we’d need to expose it as part of the C API
> 
> This seems a much smaller change than adding a LLVMConfig object.
> 
>>> * We don't need a LLVMConfig object that gets passed around.
>> 
>> For the sake of this discussion, let’s just scrap my phase two idea for a configuration object and treat that as a separate issue.
> 
> But it makes a big difference on how the first phase is handled. If we
> don't want the LLVMConfig object, the first phase should really just
> remove the static constructors and not add a stringly typed interface.

The stringly typed interface doesn’t just have to do with an LLVMConfig object, it also allows you to use non-static storage for options.

> 
>> I think that there are advantages to a string-based interface. Sean Silva actually suggested that interface when I first sent out an email about our plans to rework command line options back on 8/6. Based on Sean’s feedback and a few discussions I had offline with other LLVM contributors I thought a stringly typed interface was the best approach to eliminating both the static constructors and the static storage which are explicit goals for our project.
> 
> Sorry I missed the original discussion. Sean, would you mind
> summarizing the why of the stringly interface? Even if we do need a
> LLVMConfig object (seems unlikely), I would still suggest using some
> other key format. With strings we would suddenly be exposing every
> command line option to the C API, which seems highly undesirable.

The problem with alternate key formats from strings is it gets tricky when you start talking about supporting dynamically loaded passes and their options (which our current cl::opts do support).

Thanks,
-Chris

> 
> Cheers,
> Rafael