<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><blockquote type="cite"><div>On Aug 19, 2014, at 10:05 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 19, 2014 at 3:10 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">> There are two reasons this doesn’t work:<br>
><br>
> (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<br>
<br>
</div>This really comes up? Really, we are not talking -O2/-O3 or inlining<br>
thresholds. We are talking things like lcr-max-depth being needed for<br>
a debugging session.<br>
<div class=""><br>
> (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<br>
<br>
</div>This seems a much smaller change than adding a LLVMConfig object.<br>
<div class=""><br>
>> * We don't need a LLVMConfig object that gets passed around.<br>
><br>
> 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.<br>
<br>
</div>But it makes a big difference on how the first phase is handled. If we<br>
don't want the LLVMConfig object, the first phase should really just<br>
remove the static constructors and not add a stringly typed interface.<br>
<div class=""><br>
> 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.<br>
<br>
</div>Sorry I missed the original discussion. Sean, would you mind<br>
summarizing the why of the stringly interface? Even if we do need a<br>
LLVMConfig object (seems unlikely), I would still suggest using some<br>
other key format. With strings we would suddenly be exposing every<br>
command line option to the C API, which seems highly undesirable.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>For more details, see my lengthy musings that I just replied to the OP.<br></div><div><br></div><div>Personally, I am very wary of exposing a stringly typed interface in the C API.</div></div></div></div></div></blockquote>I have no problem with this either.</div><div><br></div><div>As an alternative, and one which is likely to be fairly stable, we could just expose ParseCommandLineOptions to the C API. That parsing will cause the options to change anyway, and there’s actually nothing to stop you from calling it multiple times to change different options at different times.</div><div><br></div><div>Pete</div><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div>
<div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></div></blockquote></div><br></body></html>