llvm dev - Mar 2009 - [LLVMdev] Patch: Prefix for ParseCommandLineOptions()

I was thinking about this more, and perhaps a more preferable solution
would have some kind of OptionGroup parameter to constructors of cl
options. This would of course be optional, with the default being a
global one.

Then, ParseCommandLineOptions() could instead take as an optional
parameter an OptionGroup, and would then only work on cl options in
that group. Would this approach be preferable?

-Alexei

On Wed, Mar 4, 2009 at 2:04 AM, Evan Cheng <echeng at apple.com>
wrote:
> I don't have any opinions about this. Chris?
>
> Evan
> On Feb 17, 2009, at 8:00 PM, Alexei Svitkine wrote:
>
>> The motivation behind this patch is that tools that use LLVM as a
>> library and want to use its command line parsing facilities may not
>> want all the various options defined in the LLVM libraries to be
>> available - simply because they may not be relevant.
>>
>> This patch adds an optional "Prefix" parameter to
>> ParseCommandLineOptions(). If set, this will make inaccessible any
>> options that do not begin with the prefix string. Any options with the
>> prefix string will act as if they were defined without that string.
>>
>> For example, if prefix string is "foo-", and
"foo-bar" is a defined
>> option, it will be displayed under --help as "--bar" and can
be used
>> as "--bar". Any options without "foo-" prefix will
not be displayed
>> under --help and will not be useable from the command line.
>>
>> -Alexei
>> <
>>
CommandLinePrefix.diff>_______________________________________________
>> 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
>

On Mar 4, 2009, at 12:15 AM, Alexei Svitkine wrote:
> I was thinking about this more, and perhaps a more preferable solution
> would have some kind of OptionGroup parameter to constructors of cl
> options. This would of course be optional, with the default being a
> global one.
Hi Alexei,

Sorry for the delay, I've been swamped lately and tend to process  
email in LIFO order :(
> Then, ParseCommandLineOptions() could instead take as an optional
> parameter an OptionGroup, and would then only work on cl options in
> that group. Would this approach be preferable?
I think that something like this would be a better approach.  There  
are a couple of related issues here:

1. In a tool like llc, I'd really only like "llc -march=x86
--help" to
show options that make sense for the x86 backend.  "llc --help" should
show *no* target-specific options.  Similarly, opt should only show  
command line options relating to enabled optimizers.

2. A tool that embeds LLVM may not want the LLVM options to be exposed  
through to its command line interface (your case).

To solve #1, we would have to add a predicate member to cl::opt's that  
are called to determine whether they are enabled.  Dependent options  
could then be parameterized appropriately.

For #2, there are a couple of different options with varying levels of  
badness:

1. You could use a compiler driver to handle translation.  This is  
what we do in clang.  In the example of clang, this handles  
translation of things like -msse3 to -mattr=+sse3 for example.

2. You can parse your actual argc/argv list with custom code, then  
assemble an argument list that you pass into the llvm CommandLine  
library to control the optimizer and backend.  This is what the cc1  
commands in llvm-gcc do: they parse the command line with the GCC  
stuff, then assemble an array of strings that gets passed into the  
command line option stuff.

What do you think?

-Chris

I like your predicate idea - that could solve both #1 and #2.

I'm wondering whether it would be possible to get the predicate stuff
automatically somehow - based on which library an option is coming
from. Something like looking at the path in __FILE__.

Then we could simply enable/disable any options based on their library
of origin (i.e. as in, one of the --libs out of llvm-config --libs).
Provided each backend is in its own library, this would work.

In your example, "llc -march=x86 --help", what would happen is this:

First, everything is enabled. When "-march=x86" is processed, it will
disable all backends except for x86. When --help is then processed, it
will only list enabled options - i.e. and thus exclude the other
backends.

For my use, I would do something like this:

Disable options from any llvm-config --libs I'm linking against that I
don't care about. (Perhaps a utility function can be added to disable
everything, and then I can just enable what I'm interested in).

-Alexei

On Mon, Mar 9, 2009 at 12:14 AM, Chris Lattner <clattner at apple.com>
wrote:
> On Mar 4, 2009, at 12:15 AM, Alexei Svitkine wrote:
>>
>> I was thinking about this more, and perhaps a more preferable solution
>> would have some kind of OptionGroup parameter to constructors of cl
>> options. This would of course be optional, with the default being a
>> global one.
>
> Hi Alexei,
>
> Sorry for the delay, I've been swamped lately and tend to process email
in
> LIFO order :(
>
>> Then, ParseCommandLineOptions() could instead take as an optional
>> parameter an OptionGroup, and would then only work on cl options in
>> that group. Would this approach be preferable?
>
> I think that something like this would be a better approach.  There are a
> couple of related issues here:
>
> 1. In a tool like llc, I'd really only like "llc -march=x86
--help" to show
> options that make sense for the x86 backend.  "llc --help" should
show *no*
> target-specific options.  Similarly, opt should only show command line
> options relating to enabled optimizers.
>
> 2. A tool that embeds LLVM may not want the LLVM options to be exposed
> through to its command line interface (your case).
>
> To solve #1, we would have to add a predicate member to cl::opt's that
are
> called to determine whether they are enabled.  Dependent options could then
> be parameterized appropriately.
>
> For #2, there are a couple of different options with varying levels of
> badness:
>
> 1. You could use a compiler driver to handle translation.  This is what we
> do in clang.  In the example of clang, this handles translation of things
> like -msse3 to -mattr=+sse3 for example.
>
> 2. You can parse your actual argc/argv list with custom code, then assemble
> an argument list that you pass into the llvm CommandLine library to control
> the optimizer and backend.  This is what the cc1 commands in llvm-gcc do:
> they parse the command line with the GCC stuff, then assemble an array of
> strings that gets passed into the command line option stuff.
>
> What do you think?
>
> -Chris
>