<div dir="ltr">So the plan is to fold all options into TargetPassConfig (and an equivalent pass for target-independent optimizations)?  If so, it would be nice to design this in such a way that you could pass arbitrary options to passes unknown at compile-time.  For example, I may have a separate library of passes for my compiler that LLVMCodeGen may not know about.  Right now I can add those passes just fine to TargetPassConfig, but I have no way of setting options on them with the current design (I could just configure the pass during construction, but this seems to fly against what you are proposing).  Perhaps TargetPassConfig can hold a String->String map of options that a pass can query...</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 17, 2013 at 4:15 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@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"><br><div><div class="im"><div>On Feb 13, 2013, at 2:32 PM, Justin Holewinski <<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>> wrote:</div>
</div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><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><br>
</div>This is a very interesting one that is orthogonal to Bill's work.  The preferred approach for this sort of thing is to change the LoopUnroll pass to take the unroll threshold as a constructor argument or a struct that wraps up all of the configuration settings.  When the pass is *default* constructed (e.g. from opt -loop-unroll), it is acceptable to have the default ctor read cl::opt variables, but the optimization pipeline should not depend on cl::opts to configure the pass.<br>



<br>
There is currently some gray area here for debug settings, and for things that are being staged in but are not on by default, but the default optimization pipeline should not be looking to cl::opt's for their settings (in an ideal world).<br>


</blockquote><div><br></div></div></div><div>I agree that this is a much cleaner solution for statically-linked passes, but how do you handle options for passes loaded at run-time?  One of the advantages of the current command-line option approach is that I can define options and have opt/llc accept them from modules linked in with "-load".  With struct-based options, I would have no way of having my library dynamically load another containing passes, and set options on those passes (unless I used some common base class that allowed me to set options).  Or perhaps a trivial solution would be to just add a new virtual method to all passes that allows clients to pass arbitrary options, like a "virtual void setOption(StringRef Option, StringRef Value) {}".  Though this use-case seems very rare…</div>
</div></div></div></div></div></blockquote><br></div><div>It is generally convenient to decouple pass configuration from construction. CodeGen does this using the TargetPassConfig analysis. It allows  pass instantiation to be configured using only Pass IDs.</div>
<div><br></div><div>Right now it's only used for subtarget options. But it would be nice to unify all codegen options for transparency and discoverability. e.g. I need to know why clang/opt/llc is not generating the same code for some test case. -print-options should tell me everything that might have affected code generation.</div>
<div><br></div><div>-Andy</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div>