[LLVMdev] Overhauling the command-line processing/codegen options code

[Andrew Trick]

On Feb 13, 2013, at 2:32 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote:
> 
> 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.
> 
> 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).
> 
> 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…

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.

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.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130217/0aaebd29/attachment.html>