<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 19, 2014 at 11:12 PM, Pete Cooper <span dir="ltr"><<a href="mailto:peter_cooper@apple.com" target="_blank">peter_cooper@apple.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 style="word-wrap:break-word"><br><div><div class=""><blockquote type="cite">
<div>On Aug 19, 2014, at 9:43 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div>One interesting issue with moving away from the current system of static initializers for cl::opt is that we will no longer have the automatic registration of all the options so that -help will print everything available and generally we will not be able to issue an error for an "unknown command line option" (without calling into any other code).</div>
</div></div></blockquote></div>Not automatic no, but in the proposal Chris puts the addOption call inside the pass initializer which is called before ParseCommandLineOptions.  This means you’ll still get options listed as you currently do, so long as you continue to calls the pass initializers before parse (something you have to do anyway to get the pass name visible to the command line)<div class="">
<br><blockquote type="cite"><div><div dir="ltr">
<div><br></div><div>The auto-registration is fundamentally tied with the globalness and the static initializers; pondering this has led me down an interesting path that has made me understand better my suggestion in the other thread. As I see it, there are two very different sorts of uses of llvm::cl in LLVM:</div>

<div><br></div><div>1. For regular command line processing. E.g. if a tool accepts an output file, then we need something that will parse the argument from the command line.</div><div><br></div><div>2. As a way to easily set up a conduit from A to B, where A is the command line and B is some place "deep" inside the LLVM library code that will do something in response to the command line.</div>

<div><br></div><div>(and, pending discussion, someday point A might include a proper programmatic interface (i.e. in a way other than hijacking the command line processing))<br></div></div></div></blockquote></div>That would be nice.  I just suggested in another thread that we expose ParseCommandLineOptions to the C API to hack around this, but a nice clean interface would of course be better.<div class="">
<br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>llvm::cl does a decent job for #1 and that is what it was designed for AFAICT; these uses of llvm::cl live outside of library code and everything is pretty happy, despite them being global and having static initializers.</div>

<div><br></div><div>The problem is that llvm::cl is not very well-suited to #2, yet it is used for #2, and that is the real problem. We need a solution to problem #2 which does not use llvm::cl. Thus, I don't think that the solution you propose here is the right direction.</div>

<div><br></div><div>The first step is to clearly differentiate between #1 and #2. I will say "command line options" for #1 and "configuration/tweak points" for #2. (maybe "library options" is better for #2; neither is perfect terminology)</div>

<div><br></div><div>The strawman I suggested in <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075503.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075503.html</a> was a stab at #2. There is no way to dodge being stringly typed since command lines are stringly typed, so really it is just a question of how long a solution stays stringly typed.</div>

<div><br></div><div>My thought process for staying stringly typed "the whole time" (possibly with some caching) comes from these two desires:</div><div>- adding a c/t point should require adding just one call into the c/t machinery (this is both for convenience and for DRY/SPOT), and </div>
</div></div></blockquote></div>Right.  The current point is in the pass initializer.</div><div><br></div><div>There is another point in the pass constructor to read the option value.  This is the only point at which something will change from being a string to its actual type and value.</div>
</div></blockquote><div><br></div><div>Yes, that is two places. My design takes it as a requirement that there be one place, which drives it to be completely different.</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">
<div style="word-wrap:break-word"><div><div class=""><br><blockquote type="cite"><div><div dir="ltr">
<div>- this change should be localized to the code being configured/tweaked</div><div>This is the thought process:</div><div><br></div><div>Note that llvm::cl is stringly typed until it parses the options. llvm::cl gives the appearance of a typed interface because it uses static initialization as a backdoor to globally transport the knowledge of the expected type to the option parsing machinery (very early in the program lifetime). Without this backdoor, we need to stay stringly typed longer, at least until we reach the "localized" place where the single call into the c/t machinery is made; this single call is the only place that has the type information needed for the c/t value to become properly typed. But there is no way to know how long it will be until we reach that point (or even *if* we reach that point; consider passes that are not run on this invocation).</div>
</div></div></blockquote></div>The current proposal exposes the type in addOption (as well as later when we get the option). So the type continues to be known to the command line parser.  Whether you want to actually type check in the command line is a point i’m open to discuss.  </div>
</div></blockquote><div><br></div><div>My solution stays stringly typed explicitly because it doesn't have that type information until later. If you have the type and option information earlier, then it is hard to imagine a reason not to resolve it immediately into a properly typed form, issue diagnostics, etc.</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"><div style="word-wrap:break-word"><div>Personally i want a command line option to be type checked because it was registered, even if no-one actually gets the value of the option later.<div class="">
<br><blockquote type="cite"><div><div dir="ltr">
<div><br></div><div>Hence my suggestion of just putting a stringly typed key-value store (or whatever) in an easily accessible place (like LLVMContext), and just translating any unrecognized command line options (ones that are not for #1) into that stringly typed storage.</div>
</div></div></blockquote></div>I’m against it being in the context because you may want to set up and reuse passes multiple times with the same options, and use that configuration to compile multiple LLVMContexts.  But I do agree that having a store with some lifetime is useful.</div>
</div></blockquote><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"><div>
<br></div><div>I think the current proposal is to have the store be a singleton, but there’s nothing to stop further work to have the storage for options be one per thread for example.  If you wanted to have one pass manager per thread with its own set of passes, configured (currently) via their own call to ParseCommandLineOptions then that would be possible with little work beyond the current proposal.<div class="">
<br><blockquote type="cite"><div><div dir="ltr">
<div><br></div><div>I agree with Rafael that "constructor arguments to passes" are not c/t points. In the future, there might be some way to integrate the two (from the referenced post, you can probably tell that I kind of like the idea of doing so), but for now, I think the clear incremental step is to attack #2 and solve it without llvm::cl. I have suggested a way to do this that I think makes sense.</div>
</div></div></blockquote></div>If you change the current proposal so that it doesn’t read cl::opt, then I think this reads to me like what is being proposed now. Really its creating a string->string map with addOption, and getting the values with getOption.  The passes don’t care (or know) whether the options are set via the command line or any other API.  I hope i’ve understood your proposal correctly here.  Please correct me otherwise.</div>
</div></blockquote><div><br></div><div>It is completely different. The Chris's proposal drops both requirements I set out which completely drive the design:</div><div>-<span style="font-family:arial,sans-serif;font-size:13px"> adding a c/t point should require adding just one call into the c/t machinery (this is both for convenience and for DRY/SPOT)</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">  + Chris's OP requires 2 calls. thus it is less convenient, and violates Don't Repeat Yourself / Single Point Of Truth</span></div><div style="font-family:arial,sans-serif;font-size:13px">
- this change should be localized to the code being configured/tweaked</div><div style="font-family:arial,sans-serif;font-size:13px">  + Some c/t points are in places that don't have a "localized" place that is called upon initialization, thus a non-localized change is required to insert the call to addOption</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">I'm open to discussing whether these are actually the true requirements we want to pursue for c/t points. However, if you assume these two as requirements, I believe that my solution makes a lot of sense.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">It might be useful split #2 into two parts, which I call Chandler and Renato, since their posts suggested each use case:</div>
<div style="font-family:arial,sans-serif;font-size:13px">- Chandler: The convenience of cl::opt is immense for developers. If we use cl::opt for things that the user of LLVM shouldn't be changing (but a developer might), then we can just not expose them to users. In production, these are not configurable, so they can be compiled down to hardcoded values and thus not have static initializers.</div>
<div style="font-family:arial,sans-serif;font-size:13px">- Renato: Have a more formalized system for exposing certain kinds of options (e.g. pass options, target options). Splitting out the Chandler part eliminates the "convenience" requirement which drove a lot of my original thoughts. Thus we can have some designated well-defined ways to declare them up-front, and they can be less convenient to use.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">However, given Owen's input, it might be that we really do not want to split #2 like this. In that case, I think my solution is a direction that makes sense:</div>
<div style="font-family:arial,sans-serif;font-size:13px">- It eliminates the static initializers that arise from usage of cl::opt in library code (the overarching problem, which impacts LLVM's usability as a library)</div>
<div style="font-family:arial,sans-serif;font-size:13px">- It opens the door to responsibly exposing access to the current cl::opt's in library code in a proper programmatic way (non-global, and even easily controlling this access by filtering keys, etc.) (Owen highlighted this as important; many users of LLVM as a library pointed out the desire to be given access to configuration/tweak points)</div>
<div style="font-family:arial,sans-serif;font-size:13px">- It does not significantly regress on the convenience of adding a new "library option"/"configuration/tweak point" in the future for development (which Chandler has highlighted is important)</div>
<div style="font-family:arial,sans-serif;font-size:13px">- It opens the door to a more formalized and well-defined system where needed (which Renato said is important)</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">I would also like to reiterate that uses of cl::opt in library code are fundamentally different from uses of cl::opt in tool code. The uses of cl::opt in library code are more about transporting a value "deep" into some part of the LLVM libraries to change their behavior, as a side-channel to the ordinary flow of information. We need to focus on that reality, and design a solution which addresses the needs to transport information deep into the library code.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">-- 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">
<div style="word-wrap:break-word"><div><br></div><div>Thanks,</div><div>Pete</div><div><div class="h5"><div><blockquote type="cite"><div><div dir="ltr">
<div><br></div><div>-- Sean Silva</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 18, 2014 at 11:49 AM, Chris Bieneman <span dir="ltr"><<a href="mailto:beanz@apple.com" target="_blank">beanz@apple.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 style="word-wrap:break-word"><div style="margin:0px">
Today command line arguments in LLVM are global variables. An example argument from Scalarizer.cpp is:</div>
<div style="margin:0px;min-height:14px"><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div style="margin:0px;font-family:Menlo">static cl::opt<bool> ScalarizeLoadStore</div><div style="margin:0px;font-family:Menlo">

  ("scalarize-load-store", cl::Hidden, cl::init(false),</div><div style="margin:0px;font-family:Menlo">   cl::desc("Allow the scalarizer pass to scalarize loads and store"));</div></blockquote><div style="margin:0px;min-height:14px">

<br></div><div style="margin:0px">This poses a problem for clients of LLVM that aren’t traditional compilers (i.e. WebKit, and Mesa). My proposal is to take a phased approach at addressing this issue.</div><div style="margin:0px;min-height:14px">

<br></div><div style="margin:0px">The first phase is to move the ownership of command line options to a singleton, OptionRegistry. The OptionRegistry can be made to work with the existing global command line definitions so that the changes to migrate options can be done in small batches. The primary purpose of this change is to move the ownership of the command line options out of the global scope, and to provide a vehicle for threading them through the compiler. At the completion of this phase, all the command line arguments will be constructed during LLVM initialization and registered under the OptionRegistry. This will replace the 100’s of static initialized cl::opt objects with a single static initialized OptionRegistry.</div>

<div style="margin:0px;min-height:14px"><br></div><div style="margin:0px">With this change options can be constructed during initialization. For the example option above the pass initialization would get a line like:</div>

<div style="margin:0px;min-height:14px"><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div style="margin:0px;font-family:Menlo">cl::OptionRegistry::CreateOption<bool>("ScalarizeLoadStore",</div>

<div style="margin:0px;font-family:Menlo">  "scalarize-load-store", cl::Hidden, cl::init(false),</div><div style="margin:0px;font-family:Menlo">  cl::desc("Allow the scalarizer pass to scalarize loads and store"));</div>

</blockquote><div style="margin:0px;min-height:14px"><br></div><div style="margin:0px">Also the pass would add a boolean member to store the value of the option which would be initialized in the pass’s constructor like this:</div>

<div style="margin:0px;min-height:14px"><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div style="margin:0px;font-family:Menlo">ScalarizeLoadStore = cl::OptionRegistry::GetValue<bool>("ScalarizeLoadStore");</div>

</blockquote><div style="margin:0px;min-height:14px"><br></div><div style="margin:0px">These two operations need to occur at separate times due to object lifespans. At the time when command lines are parsed passes have been initialized, but not constructed. That means making options live in passes doesn’t really work, but since we want the data to be part of the pass we need to initialize it during construction.</div>

<div style="margin:0px;min-height:14px"><br></div><div style="margin:0px">A large part of this phase will be finding appropriate places for all the command line options to be initialized, and identifying all the places where the option data will need to be threaded through the compiler. One of the goals here is to get rid of all global state in the compiler to (eventually) enable better multi-threading by clients like WebKit.</div>

<div style="margin:0px;min-height:14px"><br></div><div style="margin:0px">The second phase is to split the OptionRegistry into two pieces. The first piece is the parsing logic, and the second piece is the Option data store. The main goal of this phase is to make the OptionRegistry represent everything needed to parse command line options and to define a new second object, OptionStore, that is populated with values by parsing the command line. The OptionRegistry will be responsible for initializing “blank” option stores which can then be populated by either the command line parser, or API calls.</div>

<div style="margin:0px;min-height:14px"><br></div><div style="margin:0px">The OptionRegistry should remain a singleton so that the parsing logic for all options remains universally available. This is required to continue supporting plugin loadable options.</div>

<div style="margin:0px;min-height:14px"><br></div><div style="margin:0px">The OptionStore should be created when a command line is parsed, or by an API call in libraries, and can be passed through the pass manager and targets to populate option data. The OptionStore should have a lifetime independent of contexts, and pass managers because it can be re-used indiscriminately.</div>

<div style="margin:0px;min-height:14px"><br></div><div style="margin:0px">The core principle in this design is that the objects involved in parsing options only need to exist once, but you need a full list of all options in order to parse a command line. You should be able to have multiple copies of the actual stored option data. Having multiple copies of the data store is one step toward enabling two instances of LLVM in the same process to use optimization passes with different options.</div>

<div style="margin:0px;min-height:14px"><br></div><div style="margin:0px">I haven’t come up with a specific implementation proposal for this yet, but I do have some rough ideas. The basic flow that I’m thinking of is for command line parsing to create an object that maps option names to their values without any of the parsing data involved. This would allow for either parsing multiple command lines, or generally just constructing multiple option data stores. **Here is where things get foggy because I haven’t yet looked too deep.** Once you construct a data store it will get passed into the pass manager (and everywhere else that needs it), and it will be used to initialize all the option values.</div>

<div style="margin:0px;min-height:14px"><br></div><div style="margin:0px">There has been discussion about making the option store reside within the context, but this doesn’t feel right because the biggest consumer of option data is the passes, and you can use a single pass manager with multiple contexts.</div>

<div style="margin:0px;min-height:14px"><br></div><div style="margin:0px;min-height:14px">Thanks,</div><div style="margin:0px;min-height:14px">-Chris</div><div style="margin:0px;min-height:14px"></div></div><br><div style="word-wrap:break-word">

<div style="margin:0px;min-height:14px"></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div>