Patch: Prefix for ParseCommandLineOptions()

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 (11.6 KB)

I don't have any opinions about this. Chris?

Evan

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

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

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

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

We do something similar with the DEBUG macro. Users #define a DEBUG_TYPE at the top of the .cpp file, and all DEBUG macros are keyed to it.

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.

That would make sense.

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

Ok.

-Chris