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

[Sean Silva]

On Tue, Aug 26, 2014 at 5:09 PM, Pete Cooper <peter_cooper at apple.com> wrote:

>
> > On Aug 26, 2014, at 11:52 AM, Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
> >
> >> These "debugging knobs" or library level options which *aren't* exposed
> in
> >> the library's APIs are very risky to expose in a side-channel API: they
> are
> >> often completely unsupported or unsupportable options that were never
> >> intended for "production" usage. Once we expose these options via some
> API
> >> to library users, we run a very serious risk of getting locked into
> >> supporting behaviors or debugging misbehavior that were never expected
> or
> >> planned for...
> >
> > Agreed. This is my only real concern in here.
> >
> >> However, the debugging use case is real and important. So I want to
> propose
> >> that we guard many of the paths to setting these options with NDEBUG so
> that
> >> in non-asserts builds, library users can't override these options. This
> >> would mean the C++ API for setting this in LLVMContext (and the C API
> if we
> >> ever expose it there) would only support setting these in asserts
> builds. We
> >> could even sink the checking into the registry. The name should probably
> >> have "debug" in it somewhere. It would then have some
> >> InternalUnsupportedScaryBad API which is not actually in the header
> files
> >> but is used in LLVM's tools to maintain their current behavior without
> >> documenting a public API. It's not bulletproof, but it seemed that it
> would
> >> be sufficient for the debugging use cases and is a strong statement of
> >> "unsupported" IMO.
> >
> > Just to be clear, the idea is that in a release build the only way of
> > setting options is via the command line? That they can still be passed
> > to opt or llc, but they would not be considered part of the API.
> >
> >> - I really like the idea of using a 'void*' derived from some static
> tag as
> >> a way to identify uniquely each option. I also think we can use some
> minimal
> >> "reflection" techniques to significantly simplify this.
> >
> > I like it too. The reason I do is that it is one more layer in a
> > defense in depth against making our internal options part of the API.
> > The key is not just a well known value (like a string).
> >
> >> - I'd like to avoid a separate "option store". My current suggestion is
> to
> >> use the LLVMContext, and to add a context to the layers which don't
> have an
> >> LLVMContext and where these kinds of options make sense.
> >
> > I agree. There are few places in LLVM without a LLVMContext. For
> > example, there is one cl::opt in lib/MC and Joerg already has a patch
> > to turn it into a proper API.
> I disagree with this point.  The majority of the fields of the context are
> IR.  An MC only tool should not be required to link the LLVM IR just
> because they want to use a command line option.
>
> Chris’ suggestion is to make an OptionStore class and pass it throughout
> the APIs where we want to handle options.  At first the store should be a
> global singleton.  Users of options don’t need to know about the
> LLVMContext or any other unrelated data structure.  If the options are
> stored as a field of the context then that can easily be done too.
>
> If we later decide that the OptionStore should live in the LLVMContext or
> any other location then thats fine, but moving it to that point would be a
> minimal change as no APIs have to be rewritten.  Also, if we decide that we
> want the LLVMContext to have an option store, but MC level tools to be
> allowed to define their own, then that would also be possible.
>

The way I understand it, Chandler's proposal is to let any object act as an
object store if it satisfies the interface requirements (tested through
SFINAE or whatever). I'm guessing that whatever method the LLVMContext uses
to store the options will probably be reusable.

Just using a concrete ObjectStore class might be simpler than a more
loosely-coupled but more complex metaprogramming based approach (which as I
understand it is his suggestion).

-- Sean Silva


>
> Thanks,
> Pete
> >
> > Cheers,
> > Rafael
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> 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/20140826/7a8cd9dd/attachment.html>