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

[Pete Cooper]

> On Aug 19, 2014, at 10:05 PM, Sean Silva <chisophugis at gmail.com> wrote:
> 
> 
> 
> 
> On Tue, 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.
> 
> > (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.
> 
> > 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.
> 
> I think that what/how/if we expose in the C API is orthogonal to my suggestions, which are more about removing the static initializers and global state. The stringly typed interface is motivated by the need to late-resolve which options there are and what their types are; this need itself arises from eliminating the static initializers which serve as a backdoor for globally propagating type and option information on startup.
> 
> For more details, see my lengthy musings that I just replied to the OP.
> 
> Personally, I am very wary of exposing a stringly typed interface in the C API.
I have no problem with this either.

As an alternative, and one which is likely to be fairly stable, we could just expose ParseCommandLineOptions to the C API.  That parsing will cause the options to change anyway, and there’s actually nothing to stop you from calling it multiple times to change different options at different times.

Pete
> 
> -- Sean Silva
>  
> 
> Cheers,
> Rafael
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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