<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;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 20, 2014, at 3:12 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" class="">chisophugis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Wed, Aug 20, 2014 at 2:16 PM, Chris Bieneman<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:beanz@apple.com" target="_blank" class="">beanz@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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 style="word-wrap: break-word;" class="">I think Rafael’s suggestion of using the address of a global as the key to the option store gives us the ability to accomplish all our goals without introducing a string keyed option store.<br class=""><br class="">I’ve updated my patches from the original proposal to reflect those changes.<br class=""><br class="">Does this look reasonable?<br class=""></div></blockquote><div class=""><br class=""></div><div class="">The design seems to require no less than 4 not-too-close-to-each-other code changes to add an option (and LLVMOptionKey declaration, an LLVMOptionKey initialization, a call to GetValue, and a call to CreateOption). I think that the convenience for developers is an important aspect and this solution regresses significantly on that front.</div><div class=""><br class=""></div><div class="">Especially, I think that we need to evaluate the viability of an explicit CreateOption call. Do all uses of cl::opt in the library code have a relatively convenient place to put that call? If not, then we won't be able to migrate them, and we will be stuck with a partial solution. If we are willing to accept a partial solution, then the design discussion needs to change; at the very least we need to consider the scope of the partial solution.</div></div></div></blockquote><div><br class=""></div><div>Most cl::opts are in the passes, so they do have a convenient place to put the CreateOption call. There are others in places that are less convenient - like ISel lowering. However there are always initialization calls that CreateOption calls can be put into (in targets, libraries, etc).</div><div><br class=""></div><div>Fundamentally you and I are looking at this problem differently. My proposal has the following requirements:</div><div>1) Preserve existing command line option function <i class="">exactly</i> as it is today</div><div>2) Eliminate all static initializers associated with command line options and their storage</div><div>3) Design a solution that can be phased in with existing code so we don’t need to change all cl::opts in the same commit</div><div><br class=""></div><div>These requirements unfortunately made your requirements unfeasible.</div><div><br class=""></div><div>One important point I would make, is that while my changes may make it slightly less convenient to create new command line options, it does not impact the ability of a developer to manipulate the values of the options. The flags behave as they do today, and there is still one line of code somewhere that sets the value the compiler actually uses. In my example this is in the constructor for the pass.</div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><br class=""></div><div class="">-- Sean Silva</div><div class=""> </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;"><div style="word-wrap: break-word;" class=""><br class="">Thanks,<br class="">-Chris<br class=""></div><br class=""><div style="word-wrap: break-word;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 20, 2014, at 1:07 PM, Owen Anderson <<a href="mailto:resistor@mac.com" target="_blank" class="">resistor@mac.com</a>> wrote:</div><br class=""><div class=""><div style="word-wrap: break-word;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 20, 2014, at 12:16 PM, Rafael Avila de Espindola <<a href="mailto:rafael.espindola@gmail.com" target="_blank" class="">rafael.espindola@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="auto" class=""><div class="">There nothing magical about llc or opt. If you need to pass debug options to your own tools, you can do that with command line options like llc or opt, but the important factors remain:</div><div class=""><br class=""></div><div class="">* this is a debugging session, not regular use.</div><div class="">* the option storage can remain static.</div><div class="">* we don't need and API for setting the value of the option, command line is sufficient.<br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">#2 and #3 are not true.</div><div class=""><br class=""></div><div class="">• As Chris has pointed out, it’s a perfectly normal circumstance in the systems we deal with to have multiple instances of LLVM resident for different clients. Lots of applications bring in both WebKit and the OpenGL, including the browser itself via WebGL! If I’m debugging or testing one component of the system, I definitely do not want debug options I have set to cause differences in the other components.</div><div class=""><br class=""></div><div class="">• A lot of these users are not launched at the command line in a typical fashion. They’re either embedded into the address space of an existing application (which may have a totally different command line interface, or indeed none at all), or running in daemons whose lifetime is controlled by other parts of the system. Either way, setting options at the command line in not always viable.</div><div class=""><br class=""></div><div class="">I agree that llc, opt and clang *shouldn’t* be special, but everything you’re saying here is firmly rooted in a world where they are special, or at least all use cases for debugging LLVM look like them.</div><div class=""><br class=""></div><div class="">—Owen</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">Sent from my iPhone</div><div class=""><br class="">On Aug 20, 2014, at 13:42, Owen Anderson <<a href="mailto:resistor@mac.com" target="_blank" class="">resistor@mac.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 19, 2014, at 10:24 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank" class="">chandlerc@google.com</a>> wrote:</div><br class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">For example, we don't require all constants to be per-pass, and instead have per-file constants. Rafael is suggesting that one use case for cl::opt global variables is, in essence, a constant that is somewhat easier for a developer of LLVM (*not* a user) to change during debugging and active development. I don't think the desire for convenience and only supporting the default value in production contexts are completely invalid.</span></div></blockquote></div><br class=""><div class="">I think this statement ignores important debugging use cases, and over-simplifies the model of how LLVM-based frameworks are often developed. As an example, say I develop an LLVM backend for a custom co-processor, and the compiler for it runs inside the software stack of the driver for my co-processor. Per what you and Rafael are saying, the driver should not be able to programmatically set command line options to LLVM. But this ignores the reality that, when developing my backend, I may still need to be able to twiddle debugging options when debugging a live driver stack.</div><div class=""><br class=""></div><div class="">Fundamentally, you argument is rooted in a world where LLVM debugging is always done on the llc or clang binaries, where the LLVM developer can easily modify the command line arguments themselves. That’s not true of many use cases where LLVM as a shared library is relevant.</div><div class=""><br class=""></div><div class="">—Owen</div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">LLVM Developers mailing list</span><br class=""><span class=""><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="">LLVMdev@cs.uiuc.edu</a><span class="Apple-converted-space"> </span> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a></span><br class=""><span class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="">LLVMdev@cs.uiuc.edu</a><span class="Apple-converted-space"> </span> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div><br class=""></div><br class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></blockquote></div></div></blockquote></div><br class=""></body></html>