llvm dev - Aug 2014 - [LLVMdev] [RFC] Removing static initializers for command line options

> On Aug 19, 2014, at 12:32 PM, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
> 
>> I strongly feel this is the wrong decision. If you have a single
process using two LLVM clients (say WebKit and Mesa), and they both are using an
opt pass with different settings. If the storage is global this will not work.
> 
> That is only an issue if they can set the option at all.
> 
> To summarize, the point is that there are two *very* different types of
options
> 
> * Nobs for which there is not a single right answer for all users.
> There are very few of these currently and we expect it to remain like
> that. These should not use cl::opt or static storage at all. They
> should be an option passed to the constructor of the pass.  It may
> also involve exposing it to the C api and the PassManagerBuilder.
How would you suggest we expose cl::opts for modifying these options in tools
like opt? A good example of this type of option would be the options in
LoopUnrollPass.cpp.
> 
> * Options that we use during development of llvm. They are useful for
> testing, tracking a bug or enabling/disabling a feature that is still
> under development. These can use a static storage since external
> clients like webkit will never change them. We do have to avoid these
> options requiring static constructors, since otherwise the client is
> paying for something it will never use.
What about when we're debugging the WebKit JIT? For development of libraries
using LLVM it would be nice to be able to toggle these values too, which is why
Filip’s suggestion of an API like LLVMConfigSetBoolValue(Config,
"ScalarizeLoadStore", 1) would be nice.

-Chris
> 
> Cheers,
> Rafael

>> * Nobs for which there is not a single right answer for all users.
>> There are very few of these currently and we expect it to remain like
>> that. These should not use cl::opt or static storage at all. They
>> should be an option passed to the constructor of the pass.  It may
>> also involve exposing it to the C api and the PassManagerBuilder.
>
> How would you suggest we expose cl::opts for modifying these options in
tools like opt? A good example of this type of option would be the options in
LoopUnrollPass.cpp.
Opt uses the PassManagerBuilder. Opt itself could have a command line
options controlling its use of PassManagerBuilder. That is probably
fine since we expect very few of these.
>>
>> * Options that we use during development of llvm. They are useful for
>> testing, tracking a bug or enabling/disabling a feature that is still
>> under development. These can use a static storage since external
>> clients like webkit will never change them. We do have to avoid these
>> options requiring static constructors, since otherwise the client is
>> paying for something it will never use.
>
> What about when we're debugging the WebKit JIT? For development of
libraries using LLVM it would be nice to be able to toggle these values too,
which is why Filip’s suggestion of an API like LLVMConfigSetBoolValue(Config,
"ScalarizeLoadStore", 1) would be nice.
Most llvm bugs reproduce with just opt or llc, but if that is not the
case, cl::ParseCommandLineOptions when debugging seems fine.

The advantages of this setup are

* Options that are exposed to the users are done so in a very natural
way (constructor arguments).
* Internal options are still really easy to create, but now don't have
static constructors.
* We don't need a LLVMConfig object that gets passed around.
* No stringly typed interface.

Cheers,
Rafael

> On Aug 19, 2014, at 1:32 PM, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
> 
>>> * Nobs for which there is not a single right answer for all users.
>>> There are very few of these currently and we expect it to remain
like
>>> that. These should not use cl::opt or static storage at all. They
>>> should be an option passed to the constructor of the pass.  It may
>>> also involve exposing it to the C api and the PassManagerBuilder.
>> 
>> How would you suggest we expose cl::opts for modifying these options in
tools like opt? A good example of this type of option would be the options in
LoopUnrollPass.cpp.
> 
> Opt uses the PassManagerBuilder. Opt itself could have a command line
> options controlling its use of PassManagerBuilder. That is probably
> fine since we expect very few of these.
> 
>>> 
>>> * Options that we use during development of llvm. They are useful
for
>>> testing, tracking a bug or enabling/disabling a feature that is
still
>>> under development. These can use a static storage since external
>>> clients like webkit will never change them. We do have to avoid
these
>>> options requiring static constructors, since otherwise the client
is
>>> paying for something it will never use.
>> 
>> What about when we're debugging the WebKit JIT? For development of
libraries using LLVM it would be nice to be able to toggle these values too,
which is why Filip’s suggestion of an API like LLVMConfigSetBoolValue(Config,
"ScalarizeLoadStore", 1) would be nice.
> 
> Most llvm bugs reproduce with just opt or llc, but if that is not the
> case, cl::ParseCommandLineOptions when debugging seems fine.
There are two reasons this doesn’t work:

(1) Cases where I might want to set a debug variable for the WebKit JIT but not
for Mesa - if the option storage is global it will get overwritten for all users
(2) cl::ParseCommandLineOptions today is C++ API, WebKit restricts itself to the
C API, so at the least we’d need to expose it as part of the C API
> 
> The advantages of this setup are
> 
> * Options that are exposed to the users are done so in a very natural
> way (constructor arguments).
I’m on board with this, but not to the exclusion of other use cases.
> * Internal options are still really easy to create, but now don't have
> static constructors.
We’re in agreement here
> * We don't need a LLVMConfig object that gets passed around.
For the sake of this discussion, let’s just scrap my phase two idea for a
configuration object and treat that as a separate issue.
> * No stringly typed interface.
I think that there are advantages to a string-based interface. Sean Silva
actually suggested that interface when I first sent out an email about our plans
to rework command line options back on 8/6. Based on Sean’s feedback and a few
discussions I had offline with other LLVM contributors I thought a stringly
typed interface was the best approach to eliminating both the static
constructors and the static storage which are explicit goals for our project.

Thanks,
-Chris
> 
> Cheers,
> Rafael