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

[Justin Holewinski]

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...


On Sun, Feb 17, 2013 at 4:15 PM, Andrew Trick <atrick at apple.com> wrote:

>
> 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
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130218/8e711418/attachment.html>