<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 18, 2013 at 11:58 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im"><div>On Sep 17, 2013, at 10:10 AM, Andrew Trick <<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>> wrote:</div>
<blockquote type="cite">LLVM's internal command line library needs to evolve. We have an immediate need to build LLVM as a library free of static initializers, but before brute-force fixing this problem, I'd like outline the incremental steps that will lead to a desirable long term solution. We want infrastructure in place to provide an evolutionary path.</blockquote>
<div><br></div></div>Thank you for tackling this, we should have fixed this years ago.<br><br>Please do a pass over the cl::opts we have, and remove ones that are long dead or unused. Do we still need -join-liveintervals? :-)<div class="im">
<br><br><br><div><div>On Sep 17, 2013, at 12:03 PM, Daniel Dunbar <<a href="mailto:daniel@zuster.org" target="_blank">daniel@zuster.org</a>> wrote:</div><blockquote type="cite"><div dir="ltr">On Tue, Sep 17, 2013 at 11:29 AM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><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 dir="ltr">Wait, I have a terrible idea. Why don't we roll our own .init_array style appending section? I think we can make this work for all toolchains we support.</div></blockquote><div><br></div><div>Andy and I talked about this, but I don't think its worth it. My opinion is:</div>
<div>1. For tool options (the top-level llc, opt, llvm-as etc. opts) it doesn't matter.</div><div>2. For experimental options (options that we would be happy if they were compiled out of a production compiler/JIT client/whatever), it doesn't matter.</div>
<div>3. For backend options that need to always be available, lots of them probably already need to get promoted to real API.</div><div>4. For the remaining options (ones that don't need to become API, but also aren't purely experimental), many of them can probably easily be initialized by some existing initialization hook (pass initialization, target initialization).</div>
<div>5. There aren't enough options left not in those categories to motivate some kind of clever solution.</div></div></div></div></blockquote><br></div></div><div>I think that this is a great summary of the problem. Having cl::opt's compiled *out* of non-assert build by default makes a lot of sense to me, and having tool options use toolopt<> (or something) also makes perfect sense.</div>
<div><br></div><div>If you're going to go and tackle pass-specific options, I think that we should consider changing the syntax and overall design of the command line options. We already have some manual name mangling/namespacification of options (e.g. -tail-dup-limit=). Perhaps we should formalize this somehow?</div>
<span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></blockquote><div><br></div><div>In my work on LTO this summer, I kept getting a desire to be able to "parameterize" passes to see how their behavior changes. One thing I wanted to do related to some mailing list discussions was to try running a "light" inlining pass at various stages, but AFAIK LLVM doesn't have a way to do something like `opt ... -simple-inliner(40) ... -inline`. In one of Shuxin's preliminary LTO experiment patches, in order to get a SimpleInliner with threshold 40, he had to add C++ code (admittedly little, but still requiring a recompile, and the threshold was hardcoded).</div>
<div><br></div><div>Another example where "pass parametrization" was a huge win that I ran into this summer was with the ASan instrumentation pass that uses cl::opt's for this (it has a LOT of cl::opt's btw). Being able to dynamically configure the shadow offset and scale with the existing SDK compiler was a crucial productivity win, so losing that would be a shame. Maybe there could be something like a clang option to allow `-configure-pass=asan(mapping-scale=...,offset-log=...)` that actually associates that configuration with ASan? Idk (that's just off the top of my head).</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="HOEnZb"><font color="#888888"><div>
</div><div>-Chris</div><br></font></span></div><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>
<br></blockquote></div><br></div></div>