<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 9:28 AM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@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="">> I haven’t yet worked out the cleanest way to do this.  There’s 2 options I<br>

> think.  Either make some kind of command line registration available via the<br>
> PassRegistry already passed to initialize, or we add another parameter to<br>
> initialize which is the command line registry.<br>
><br>
> What do you think?<br>
><br>
<br>
</div>I was thinking about this a while ago w.r.t. the backend options<br>
coming from clang as well. One thought would be to add<br>
elements/structures onto something like the LLVMContext and have them<br>
be able to be set via populating a structure while we take the command<br>
lines out/separated/etc that can also fill in the structure.<br>
<br>
I think this would work for most of the command line options within<br>
the passes as well, just give each one their own options structure?<br></blockquote><div><br></div><div>I once thought a bit about this situation, and the (probably hopelessly naive) thing that I came up with is something like adding roughly a std::map<StringRef,StringRef> to the LLVMContext, which is essentially just a "string'ly-typed" key-value store. Then we have a couple helper functions that deserialize their respective values, e.g.</div>
<div><br></div><div>int NumTimes = getParameter<int>(KVs,"foo-num-times");</div><div>StringRef CFGRoot = getParameter<StringRef>(KVs,"foo-cfgroot");</div><div>std::vector<StringRef> UsedFuncs = getParameter<std::vector<StringRef>>(KVs,"foo-used-funcs");</div>
<div>(a layer of caching of the deserialized values might be useful).</div><div><br></div><div>The idea is to avoid having a large impedance mismatch between command line options (which are essentially string'ly typed) and the in-memory configuration storage. </div>
For tools, we have some sort of translation layer that pulls command line options into the KV structure. For more modular needs, the KV structure can be maintained manually and passed in at the desired granularity.</div><div class="gmail_quote">
<br><div>We can also have pass creation functions accept such a KV structure (if relevant) for configuration stuff (or maybe have each pass have an associated helper function that accepts a KV structure and turns it into the actual configuration struct that the pass accepts).</div>
<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>
*shrug*<br>
<span class=""><font color="#888888"><br>
-eric<br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<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" 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></div></blockquote></div><br></div></div>