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

[Sean Silva]

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.

-- Sean Silva


>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140819/986c2e8b/attachment.html>