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

Chandler Carruth chandlerc at google.com
Tue Aug 26 17:31:49 PDT 2014


On Tue, Aug 26, 2014 at 5:09 PM, Pete Cooper <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.

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


More information about the llvm-dev mailing list