<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 26, 2014, at 5:31 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Aug 26, 2014 at 5:09 PM, Pete Cooper <span dir="ltr" class=""><<a href="mailto:peter_cooper@apple.com" target="_blank" class="">peter_cooper@apple.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="adM HOEnZb"><div class="">>> - I'd like to avoid a separate "option store". My current suggestion is to<br class="">
>> use the LLVMContext, and to add a context to the layers which don't have an<br class="">
>> LLVMContext and where these kinds of options make sense.<br class="">
><br class="">
> I agree. There are few places in LLVM without a LLVMContext. For<br class="">
> example, there is one cl::opt in lib/MC and Joerg already has a patch<br class="">
> to turn it into a proper API.<br class="">
</div></div>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.</blockquote></div>
<br class=""></div><div class="gmail_extra">Sorry, this is my fault, I phrased something poorly.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br class=""></div><div class="gmail_extra">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.</div></div></div></blockquote>Sounds good. Thanks for clarifying that.</div><div><br class=""></div><div>Thanks,</div><div>Pete<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">
<div class="gmail_extra"><br class=""></div><div class="gmail_extra">-Chandler</div></div>
</div></blockquote></div><br class=""></body></html>