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

[Pete Cooper]

> On Aug 26, 2014, at 5:31 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> 
> On Tue, Aug 26, 2014 at 5:09 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote:
> >> - 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.
> 
> Sorry, this is my fault, I phrased something poorly.
> 
> When I said "add a context to the layers ..." I didn't mean to add an LLVMContext to them. I agree, that's crazy. =] I meant add some context object *for* that layer. Maybe an MCContext. This would *only* traffic in the shared context and state needed by that layer, not any other layer. If the layer needs these debug options, they can expose a generic interface from that context and the option management code will happily use it.
> 
> The reason I mention this is that I don't want us to develop N different objects which are essentially "side cars" to carry additional state around a layer of abstraction. We've been using LLVMContext to do that successfully at the IR layer. At other layers where we need to do the same, I'd like to add a single context *type* to represent that layer, and use objects of that type to pass around both options and any other common structures needed at that layer.
Sounds good.  Thanks for clarifying that.

Thanks,
Pete
> 
> -Chandler

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