[LLVMdev] Patch: Prefix for ParseCommandLineOptions()

[Alexei Svitkine]

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
>