llvm dev - Sep 2013 - [LLVMdev] [RFC] Internal command line options should not be statically initialized.

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.

In the near term, clients who need llvm-the-library with no static initializers
will build with LLVM_NO_STATICINIT. In this mode, existing users of cl::opt will
default to being optimized away as constant initializers, and those options will
not be available for command line parsing.

A new option class will need be defined, cl::toolopt. Initially, this will share
the implementation and API with cl::opt. The only difference will be that
cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required for tool
support can simply be type-renamed to toolopt. Since these are not defined in a
library, their static initializers are irrelevant.

Eventually, we would like to eliminate the special LLVM_NO_STATICINIT build
mode. This can be done by making the -Asserts build just as strict. In the
meantime, we would like to run as many unit tests as possible with
LLVM_NO_STATICINIT builds. This will be solved by gradually moving cl::opt
definitions buried within LLVM libraries to to a new pattern that avoids static
initialization.

One easy pattern to follow is to register the option during pass initialization
with all the convenient flags and parameters, but refer to a globally defined
option storage that enforces the singleton and provides visibility. As long as
pass initialization happens before parseCommandLine, usage should be consistent.

Strawman:

cl::optval<bool> MyOption; // Just the storage, no initialization.

MyPass() {
  // Only registers an option with the same optval once.
  Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
                         cl::desc("Descriptive string..."), );
}

-Andy

Hey Andy
> One easy pattern to follow is to register the option during pass
initialization with all the convenient flags and parameters, but refer to a
globally defined option storage that enforces the singleton and provides
visibility. As long as pass initialization happens before parseCommandLine,
usage should be consistent.
> 
> Strawman:
> 
> cl::optval<bool> MyOption; // Just the storage, no initialization.
> 
> MyPass() {
>  // Only registers an option with the same optval once.
>  Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
>                         cl::desc("Descriptive string..."), );
> }
Given Chandler's upcoming work on the pass manager, should we assume that
multithreaded passes are a future possibility.  If so, would the above variable
need to be static inside the constructor, or is there some better way to
initialize it only once?  Or perhaps cl options just don't make any sense in
a multithreaded context and you can ignore my ramblings.

Thanks,
Pete
> 
> -Andy
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

----- Original Message -----
> 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.
> 
> In the near term, clients who need llvm-the-library with no static
> initializers will build with LLVM_NO_STATICINIT. In this mode,
> existing users of cl::opt will default to being optimized away as
> constant initializers, and those options will not be available for
> command line parsing.
> 
> A new option class will need be defined, cl::toolopt. Initially, this
> will share the implementation and API with cl::opt. The only
> difference will be that cl::toolopt is immune to LLVM_NO_STATICINIT.
> Options that are required for tool support can simply be
> type-renamed to toolopt. Since these are not defined in a library,
> their static initializers are irrelevant.
> 
> Eventually, we would like to eliminate the special LLVM_NO_STATICINIT
> build mode. This can be done by making the -Asserts build just as
> strict. In the meantime, we would like to run as many unit tests as
> possible with LLVM_NO_STATICINIT builds. This will be solved by
> gradually moving cl::opt definitions buried within LLVM libraries to
> to a new pattern that avoids static initialization.
> 
> One easy pattern to follow is to register the option during pass
> initialization with all the convenient flags and parameters, but
> refer to a globally defined option storage that enforces the
> singleton and provides visibility. As long as pass initialization
> happens before parseCommandLine, usage should be consistent.
> 
> Strawman:
> 
> cl::optval<bool> MyOption; // Just the storage, no initialization.
> 
> MyPass() {
>   // Only registers an option with the same optval once.
>   Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
>                          cl::desc("Descriptive string..."), );
> }
Sounds good to me.

Will this make it safe again to use -backend-option in Clang? [Not saying that
we *want* to do that, but that's a separate matter].

Regardless of the answer to that question, it might make sense for multiple
target backends to register options with the same name (currently, for example,
both the X86 and PPC backends have options to force the use of a base pointer,
and they need to have different names), it would be nice if that could be
cleaned up as part of this.

 -Hal
> 
> -Andy
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On Sep 17, 2013, at 10:18 AM, Pete Cooper <peter_cooper at apple.com>
wrote:
> Hey Andy
> 
>> One easy pattern to follow is to register the option during pass
initialization with all the convenient flags and parameters, but refer to a
globally defined option storage that enforces the singleton and provides
visibility. As long as pass initialization happens before parseCommandLine,
usage should be consistent.
>> 
>> Strawman:
>> 
>> cl::optval<bool> MyOption; // Just the storage, no
initialization.
>> 
>> MyPass() {
>> // Only registers an option with the same optval once.
>> Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
>>                        cl::desc("Descriptive string..."), );
>> }
> Given Chandler's upcoming work on the pass manager, should we assume
that multithreaded passes are a future possibility.  If so, would the above
variable need to be static inside the constructor, or is there some better way
to initialize it only once?  Or perhaps cl options just don't make any sense
in a multithreaded context and you can ignore my ramblings.

Thanks for giving me a chance to clarify and fix a typo.

Normally, you wouldn’t need to capture the Option object at all, just register
it:

MyPass() {
  cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
                       cl::desc("Descriptive string..."), );
}

The globally defined option storage will have an initialized flag and
registerOpt will do a CAS on that for thread safety. Subsequent calls to
registerOpt with the same option storage will do nothing.

Now, we might want to capture the option object as such:

MyPass() {
  Option &MyOpt = cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
                                  cl::desc("Descriptive string..."),
);
}

Subsequent calls to registerOpt will just return the existing Option object.

-Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130917/dfb5f28e/attachment.html>

Hi Andy,

I definitely agree with the desire to remove command line options and
having them be initialized as part of the pass would be general
goodness. However, a few possible issues:

a) a number of command line options aren't really connected to passes
per-se (backend options)
b) "As long as pass initialization happens before parseCommandLine,
usage should be consistent." I'm thinking this isn't going to work
for
the opt tool at least :)

Thoughts?

-eric


On Tue, Sep 17, 2013 at 10:10 AM, Andrew Trick <atrick at apple.com>
wrote:
> 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.
>
> In the near term, clients who need llvm-the-library with no static
initializers will build with LLVM_NO_STATICINIT. In this mode, existing users of
cl::opt will default to being optimized away as constant initializers, and those
options will not be available for command line parsing.
>
> A new option class will need be defined, cl::toolopt. Initially, this will
share the implementation and API with cl::opt. The only difference will be that
cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required for tool
support can simply be type-renamed to toolopt. Since these are not defined in a
library, their static initializers are irrelevant.
>
> Eventually, we would like to eliminate the special LLVM_NO_STATICINIT build
mode. This can be done by making the -Asserts build just as strict. In the
meantime, we would like to run as many unit tests as possible with
LLVM_NO_STATICINIT builds. This will be solved by gradually moving cl::opt
definitions buried within LLVM libraries to to a new pattern that avoids static
initialization.
>
> One easy pattern to follow is to register the option during pass
initialization with all the convenient flags and parameters, but refer to a
globally defined option storage that enforces the singleton and provides
visibility. As long as pass initialization happens before parseCommandLine,
usage should be consistent.
>
> Strawman:
>
> cl::optval<bool> MyOption; // Just the storage, no initialization.
>
> MyPass() {
>   // Only registers an option with the same optval once.
>   Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
>                          cl::desc("Descriptive string..."), );
> }
>
> -Andy
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Sep 17, 2013, at 10:31 AM, Eric Christopher <echristo at gmail.com>
wrote:
> Hi Andy,
> 
> I definitely agree with the desire to remove command line options and
> having them be initialized as part of the pass would be general
> goodness. However, a few possible issues:
> 
> a) a number of command line options aren't really connected to passes
> per-se (backend options)
We don’t have to ban the old-style options. They can live-on indefinitely for
experimental purposes, but if test cases need to use those options, they would
need a REQUIRES: asserts line.

For options that we actually want to make available to tools (and general
testing) we have a couple possibilities:

Create a hook that can be called before command line parsing, like
initializeXXPass.

Raise those options into an API and define the command line interface at the
tool level instead. This seems like something we want to do anyway, but I’m not
proposing anything definite yet (I’m happy as long we’re moving in that
direction). We may want to raise some options all the way to function
attributes.
> b) "As long as pass initialization happens before parseCommandLine,
> usage should be consistent." I'm thinking this isn't going to
work for
> the opt tool at least :)
> 
> Thoughts?
I think all the standard passes will be initialized up front. The problem would
be with plugins using -load, but I fail to see how that can work with -help
today anyway.

-Andy
> 
> -eric
> 
> 
> On Tue, Sep 17, 2013 at 10:10 AM, Andrew Trick <atrick at apple.com>
wrote:
>> 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.
>> 
>> In the near term, clients who need llvm-the-library with no static
initializers will build with LLVM_NO_STATICINIT. In this mode, existing users of
cl::opt will default to being optimized away as constant initializers, and those
options will not be available for command line parsing.
>> 
>> A new option class will need be defined, cl::toolopt. Initially, this
will share the implementation and API with cl::opt. The only difference will be
that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required for
tool support can simply be type-renamed to toolopt. Since these are not defined
in a library, their static initializers are irrelevant.
>> 
>> Eventually, we would like to eliminate the special LLVM_NO_STATICINIT
build mode. This can be done by making the -Asserts build just as strict. In the
meantime, we would like to run as many unit tests as possible with
LLVM_NO_STATICINIT builds. This will be solved by gradually moving cl::opt
definitions buried within LLVM libraries to to a new pattern that avoids static
initialization.
>> 
>> One easy pattern to follow is to register the option during pass
initialization with all the convenient flags and parameters, but refer to a
globally defined option storage that enforces the singleton and provides
visibility. As long as pass initialization happens before parseCommandLine,
usage should be consistent.
>> 
>> Strawman:
>> 
>> cl::optval<bool> MyOption; // Just the storage, no
initialization.
>> 
>> MyPass() {
>>  // Only registers an option with the same optval once.
>>  Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
>>                         cl::desc("Descriptive string..."), );
>> }
>> 
>> -Andy
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Isnt all the command line options only relevant to the driver, so if all 
the command line options are migrated to the driver, the library will be 
free from static initializers.

Doesnt this make it more cleaner ?

Thanks

Shankar Easwaran

On 9/17/2013 12:10 PM, Andrew Trick wrote:
> 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.
>
> In the near term, clients who need llvm-the-library with no static
initializers will build with LLVM_NO_STATICINIT. In this mode, existing users of
cl::opt will default to being optimized away as constant initializers, and those
options will not be available for command line parsing.
>
> A new option class will need be defined, cl::toolopt. Initially, this will
share the implementation and API with cl::opt. The only difference will be that
cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required for tool
support can simply be type-renamed to toolopt. Since these are not defined in a
library, their static initializers are irrelevant.
>
> Eventually, we would like to eliminate the special LLVM_NO_STATICINIT build
mode. This can be done by making the -Asserts build just as strict. In the
meantime, we would like to run as many unit tests as possible with
LLVM_NO_STATICINIT builds. This will be solved by gradually moving cl::opt
definitions buried within LLVM libraries to to a new pattern that avoids static
initialization.
>
> One easy pattern to follow is to register the option during pass
initialization with all the convenient flags and parameters, but refer to a
globally defined option storage that enforces the singleton and provides
visibility. As long as pass initialization happens before parseCommandLine,
usage should be consistent.
>
> Strawman:
>
> cl::optval<bool> MyOption; // Just the storage, no initialization.
>
> MyPass() {
>    // Only registers an option with the same optval once.
>    Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
>                           cl::desc("Descriptive string..."), );
> }
>
> -Andy
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

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.

We'd have something like:

struct PODOptData {
  const char *FlagName;
...  // Common POD stuff, can be initialized at ParseCommandLine time.
};

LLVM_SECTION(".llvmopt")
PODOptData OptionRegisterer = { "foo_flag", ... };

I know the COFF magic to get the section bounds to form an array, and I
know it exists for ELF, but I don't know how to do it on Darwin.



On Tue, Sep 17, 2013 at 10:10 AM, Andrew Trick <atrick at apple.com>
wrote:
> 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.
>
> In the near term, clients who need llvm-the-library with no static
> initializers will build with LLVM_NO_STATICINIT. In this mode, existing
> users of cl::opt will default to being optimized away as constant
> initializers, and those options will not be available for command line
> parsing.
>
> A new option class will need be defined, cl::toolopt. Initially, this will
> share the implementation and API with cl::opt. The only difference will be
> that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required
> for tool support can simply be type-renamed to toolopt. Since these are not
> defined in a library, their static initializers are irrelevant.
>
> Eventually, we would like to eliminate the special LLVM_NO_STATICINIT
> build mode. This can be done by making the -Asserts build just as strict.
> In the meantime, we would like to run as many unit tests as possible with
> LLVM_NO_STATICINIT builds. This will be solved by gradually moving cl::opt
> definitions buried within LLVM libraries to to a new pattern that avoids
> static initialization.
>
> One easy pattern to follow is to register the option during pass
> initialization with all the convenient flags and parameters, but refer to a
> globally defined option storage that enforces the singleton and provides
> visibility. As long as pass initialization happens before parseCommandLine,
> usage should be consistent.
>
> Strawman:
>
> cl::optval<bool> MyOption; // Just the storage, no initialization.
>
> MyPass() {
>   // Only registers an option with the same optval once.
>   Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
>                          cl::desc("Descriptive string..."), );
> }
>
> -Andy
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130917/0a50cefd/attachment.html>

So since you are rolling that then why don't just use the simpler ARM ELF
ABI for that? armv7a ABI on i386 and AArch64 ABI in amd64? That init-array are
dead simple to use.

Sent from my iPhone
> On 2013年9月18日, at 2:29, Reid Kleckner <rnk at google.com> wrote:
> 
> 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.
> 
> We'd have something like:
> 
> struct PODOptData {
>   const char *FlagName;
> ...  // Common POD stuff, can be initialized at ParseCommandLine time.
> };
> 
> LLVM_SECTION(".llvmopt")
> PODOptData OptionRegisterer = { "foo_flag", ... };
> 
> I know the COFF magic to get the section bounds to form an array, and I
know it exists for ELF, but I don't know how to do it on Darwin.
> 
> 
> 
>> On Tue, Sep 17, 2013 at 10:10 AM, Andrew Trick <atrick at
apple.com> wrote:
>> 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.
>> 
>> In the near term, clients who need llvm-the-library with no static
initializers will build with LLVM_NO_STATICINIT. In this mode, existing users of
cl::opt will default to being optimized away as constant initializers, and those
options will not be available for command line parsing.
>> 
>> A new option class will need be defined, cl::toolopt. Initially, this
will share the implementation and API with cl::opt. The only difference will be
that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required for
tool support can simply be type-renamed to toolopt. Since these are not defined
in a library, their static initializers are irrelevant.
>> 
>> Eventually, we would like to eliminate the special LLVM_NO_STATICINIT
build mode. This can be done by making the -Asserts build just as strict. In the
meantime, we would like to run as many unit tests as possible with
LLVM_NO_STATICINIT builds. This will be solved by gradually moving cl::opt
definitions buried within LLVM libraries to to a new pattern that avoids static
initialization.
>> 
>> One easy pattern to follow is to register the option during pass
initialization with all the convenient flags and parameters, but refer to a
globally defined option storage that enforces the singleton and provides
visibility. As long as pass initialization happens before parseCommandLine,
usage should be consistent.
>> 
>> Strawman:
>> 
>> cl::optval<bool> MyOption; // Just the storage, no
initialization.
>> 
>> MyPass() {
>>   // Only registers an option with the same optval once.
>>   Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
>>                          cl::desc("Descriptive string..."),
);
>> }
>> 
>> -Andy
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130918/5ac41347/attachment.html>

On Tue, Sep 17, 2013 at 11:29 AM, Reid Kleckner <rnk at google.com> wrote:
> 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.
>
Andy and I talked about this, but I don't think its worth it. My opinion is:
1. For tool options (the top-level llc, opt, llvm-as etc. opts) it doesn't
matter.
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.
3. For backend options that need to always be available, lots of them
probably already need to get promoted to real API.
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).
5. There aren't enough options left not in those categories to motivate
some kind of clever solution.

Another way of looking at it is: the implicitly initialized option syntax
is really convenient for experimental options, but those are exactly the
ones that don't cause problems because we could be happy just compiling
them out. For almost everything else, the implicitly initialized
"feature"
of llvm::cl isn't all that useful, and is in some cases actively harmful.

 - Daniel

We'd have something like:
>
> struct PODOptData {
>   const char *FlagName;
> ...  // Common POD stuff, can be initialized at ParseCommandLine time.
> };
>
> LLVM_SECTION(".llvmopt")
> PODOptData OptionRegisterer = { "foo_flag", ... };
>
> I know the COFF magic to get the section bounds to form an array, and I
> know it exists for ELF, but I don't know how to do it on Darwin.
>
>
>
> On Tue, Sep 17, 2013 at 10:10 AM, Andrew Trick <atrick at apple.com>
wrote:
>
>> 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.
>>
>> In the near term, clients who need llvm-the-library with no static
>> initializers will build with LLVM_NO_STATICINIT. In this mode, existing
>> users of cl::opt will default to being optimized away as constant
>> initializers, and those options will not be available for command line
>> parsing.
>>
>> A new option class will need be defined, cl::toolopt. Initially, this
>> will share the implementation and API with cl::opt. The only difference
>> will be that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that
are
>> required for tool support can simply be type-renamed to toolopt. Since
>> these are not defined in a library, their static initializers are
>> irrelevant.
>>
>> Eventually, we would like to eliminate the special LLVM_NO_STATICINIT
>> build mode. This can be done by making the -Asserts build just as
strict.
>> In the meantime, we would like to run as many unit tests as possible
with
>> LLVM_NO_STATICINIT builds. This will be solved by gradually moving
cl::opt
>> definitions buried within LLVM libraries to to a new pattern that
avoids
>> static initialization.
>>
>> One easy pattern to follow is to register the option during pass
>> initialization with all the convenient flags and parameters, but refer
to a
>> globally defined option storage that enforces the singleton and
provides
>> visibility. As long as pass initialization happens before
parseCommandLine,
>> usage should be consistent.
>>
>> Strawman:
>>
>> cl::optval<bool> MyOption; // Just the storage, no
initialization.
>>
>> MyPass() {
>>   // Only registers an option with the same optval once.
>>   Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
>>                          cl::desc("Descriptive string..."),
);
>> }
>>
>> -Andy
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130917/af818c1f/attachment.html>

On Sep 17, 2013, at 10:25 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
>> 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.
>> 
>> In the near term, clients who need llvm-the-library with no static
>> initializers will build with LLVM_NO_STATICINIT. In this mode,
>> existing users of cl::opt will default to being optimized away as
>> constant initializers, and those options will not be available for
>> command line parsing.
>> 
>> A new option class will need be defined, cl::toolopt. Initially, this
>> will share the implementation and API with cl::opt. The only
>> difference will be that cl::toolopt is immune to LLVM_NO_STATICINIT.
>> Options that are required for tool support can simply be
>> type-renamed to toolopt. Since these are not defined in a library,
>> their static initializers are irrelevant.
>> 
>> Eventually, we would like to eliminate the special LLVM_NO_STATICINIT
>> build mode. This can be done by making the -Asserts build just as
>> strict. In the meantime, we would like to run as many unit tests as
>> possible with LLVM_NO_STATICINIT builds. This will be solved by
>> gradually moving cl::opt definitions buried within LLVM libraries to
>> to a new pattern that avoids static initialization.
>> 
>> One easy pattern to follow is to register the option during pass
>> initialization with all the convenient flags and parameters, but
>> refer to a globally defined option storage that enforces the
>> singleton and provides visibility. As long as pass initialization
>> happens before parseCommandLine, usage should be consistent.
>> 
>> Strawman:
>> 
>> cl::optval<bool> MyOption; // Just the storage, no
initialization.
>> 
>> MyPass() {
>>  // Only registers an option with the same optval once.
>>  Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
>>                         cl::desc("Descriptive string..."), );
>> }
> 
> Sounds good to me.
> 
> Will this make it safe again to use -backend-option in Clang? [Not saying
that we *want* to do that, but that's a separate matter].
> 
> Regardless of the answer to that question, it might make sense for multiple
target backends to register options with the same name (currently, for example,
both the X86 and PPC backends have options to force the use of a base pointer,
and they need to have different names), it would be nice if that could be
cleaned up as part of this.
The only solution I have for this is to raise both options into the
target-independent API. Currently, that means adding it to TargetOptions and
moving the flag to CommandLineFlags.h. I feel like the way to improve this is by
redesigning TargetOptions to be less ad-hoc. It would be nice to define an
option string in one place and allow the option to be overridden as a function
attribute or command line -mllvm option. We should probably have a declarative
option syntax for this like clang.

-Andy
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130917/ab9132de/attachment.html>

On Sep 17, 2013, at 11:25 AM, Shankar Easwaran <shankare at
codeaurora.org> wrote:
> Isnt all the command line options only relevant to the driver, so if all
the command line options are migrated to the driver, the library will be free
from static initializers.
> 
> Doesnt this make it more cleaner ?
Yes, but less convenient for developing experimental passes. I think we want to
move in this direction, as I explained to Eric. We don’t have a good framework
for tool options, and solving that problem will take a lot more time than what
I’ve proposed so far.

-Andy
> On 9/17/2013 12:10 PM, Andrew Trick wrote:
>> 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.
>> 
>> In the near term, clients who need llvm-the-library with no static
initializers will build with LLVM_NO_STATICINIT. In this mode, existing users of
cl::opt will default to being optimized away as constant initializers, and those
options will not be available for command line parsing.
>> 
>> A new option class will need be defined, cl::toolopt. Initially, this
will share the implementation and API with cl::opt. The only difference will be
that cl::toolopt is immune to LLVM_NO_STATICINIT. Options that are required for
tool support can simply be type-renamed to toolopt. Since these are not defined
in a library, their static initializers are irrelevant.
>> 
>> Eventually, we would like to eliminate the special LLVM_NO_STATICINIT
build mode. This can be done by making the -Asserts build just as strict. In the
meantime, we would like to run as many unit tests as possible with
LLVM_NO_STATICINIT builds. This will be solved by gradually moving cl::opt
definitions buried within LLVM libraries to to a new pattern that avoids static
initialization.
>> 
>> One easy pattern to follow is to register the option during pass
initialization with all the convenient flags and parameters, but refer to a
globally defined option storage that enforces the singleton and provides
visibility. As long as pass initialization happens before parseCommandLine,
usage should be consistent.
>> 
>> Strawman:
>> 
>> cl::optval<bool> MyOption; // Just the storage, no
initialization.
>> 
>> MyPass() {
>>   // Only registers an option with the same optval once.
>>   Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden,
>>                          cl::desc("Descriptive string..."),
);
>> }
>> 
>> -Andy
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by the Linux Foundation
>